CENTRAL PUGET SOUND REGIONAL TRANSIT AUTHORITY 



PAGE OF PAGES 

SoundTransit 

CHANGE ORDER 

1 

1 

1. CHANGE ORDER NO. : 
Enter option # to the right of 
CO # if exercising an option 

2. CHANGE ORDER EFFECTIVE DATE: 

3. CONTRACT DATE: 

4. : MODIFICATION OF 

CONTRACT or 

PURCHASE/ORDER NO: 

i.OI 


2. 02/26/2019 

3. 10/02/18 

4. RTA/RP 0119-17 
171757 OP 

5. ISSUED BY: 

Central Puget Sound Regional Transit Authority 
(Sound Transit) 

401 South Jackson Street 

Seattle, WA 98104-2826 

6A. NAME AND ADDRESS OF CONTRACTOR 
(No. Street, City, State and ZIP Code): 

Roland Staib, President & CEO 

IN IT Innovations in Transportation, Inc. 

424 Network Station 

Chesapeake, VA 23320 

6B. Contract Price at Time of Award: 

6D. Present Contract Price as a result of 
previous Contract Modifications: 

7A. Contract Completion Date at Time of 
Award: 

7B. Days Extended or Decreased by 
this Modification of Contract): 

$94,940,044.00 

$94,940,044.00 

10/01/22 

none 

6C. Price Adjustment Total as a result of 
all previous Contract Modifications: 

6E. Price Increase (Decrease) by this 
Modification of Contract: 

7C. Present Contract Completion Date as a result of previous Contract Modifications: 

$0.00 

($700,000.00) 

10/01/22 

6F. REVISED (NEW) CONTRACT PRICE: 

8. REVISED (NEW) CONTRACT COMPLETION DATE: 

$94,240,044.00 

No change 


9. THIS ITEM MODIFIES THE CONTRACT/ORDER NUMBER AS FURTHER DESCRIBED IN ITEM 11. 

9A. THIS CHANGE ORDER IS ISSUED PURSUANT TO: (Specify authority) Article 4, Changes _ 

10. IMPORTANT: Contractor □ is not, is required to sign this document. 

11. DESCRIPTION OF CHANGE: 

No changes to the scope of work are made by this change order. 

1. The Contract Price is hereby changed from $94,940,044 to $94,240,044. 

2. This change order replaces the current Price Section 5, Contract Price Schedule with the prices 
provided the price sheet submitted by the Contractor on September 13, 2018. See Price Section 
5, Contract Price Schedule attached to this Change Order 01. 

3. This change order inserts Tab 9 (attached to this Change Order 01) of the Contractor’s revised 
proposal dated June 8, 2018. 


13 if checked, description is continued on ST-Change Order -Continuation page(s) 


Except as provided herein, all terms and conditions of the above referenced contract remain unchanged and in full force and effect. 


12A. CONTRACTOR: NAME AND TITLE OF SIGNER (Type or print) 

13A.. SOUNDTRANSIT: NAME AND TITLE OF AUTHORIZED 
REPRESENTATIVE (Type or print) 

Roland Staib, President & CEO 

Michael Harbour, Deputy Chief Executive Officer 

12B. CONTRACTOR 

12C. DATE SIGNED 

13B. CENTRAL PUGET SOUND REGIONAL TRANSIT 
AUTHORITY [SOUND TRANSIT] 

13C. DATE SIGNED 

BY 


BY 


(Signature of person authorized to sign) 





(Signature of person authorized to sign) 
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SECTION 08 - CONTRACT PRICE SCHEDULE 


CONTRACT PRICING 

The Contractor will be compensated upon Acceptance of the deliverable(s) for each specific item, as described in 
the Contract Documents. Lump Sums and Hourly Rates are fully-burdened which is inclusive of direct hourly rates, 
direct costs including travel, parking, overhead, and profit. Total compensation for each item will not exceed the 
amount identified for that item as follows. Contract Pricing will remain constant throughout the term of the 
agreement - no price escalation will apply regardless of market conditions. 

The ORCA Agencies may, in their discretion, pay for extraordinary, unanticipated costs, subject to prior written 
approval. 

In the "Unit" column: "LS" means lump sum; "EA" means each; "YR" means per year; "MO" means per month; and 
"HR" means per hour. 

Some of the Lump Sum prices are divided into Milestone or Partial payments as described in the Milestone/Partial 
Payment Schedule below. 

Item numbers in the "Item No." column are for reference only. They are not intended to be in order and some 
numbers may be missing as they were removed during the contract negotiation process. 

PRICE SECTION 1 - IMPLEMENTATION SERVICES 


Item 

No. 

SOW 

Ref. 

Description 

Unit 

Unit Price 


Program and Contract Management 

1.01 

2 

Program & Contract Management (NTP to System 
Acceptance) 

LS 

$ 3,735,467.80 


UI/UX Consulting 

1.01a 

2 

Project Management, Project Initiation and Onboarding 

LS 

$ 694,212.00 

1.01b 

2 

Corporate Design and Style Guide 

LS 

$ 271,743.00 

1.01c 

2 

Website Design Guide 

LS 

$ 113,818.00 

l.Old 

2 

Validator 

LS 

$ 149,042.00 

l.Ole 

2 

Driver Display Unit 

LS 

$ 98,504.00 

l.Olf 

2 

Front Office Ticket Sales 

LS 

$ 103,404.00 

l.Olg 

2 

Vending Machines 

LS 

$ 134,340.00 


Software Escrow 

l.Olh 

2 

Initial Deposit - Level 1 Escrow (or equivalent) 

See Attachment F for Escrow Agreement 

LS 

$ 56,456.00 


Installation and Transition Services 

1.02 

2 

Transition Strategy and Planning 

LS 

$ 546,189.70 

1.03 

2 

Back-Office Installation and Configuration, Including 
Documentation 

LS 

$ 732,701.36 

1.04 

2 

Field Device Site Surveys and Prototyping 

LS 

$ 63,307.96 

1.05a 

2 

Onboard Equipment (validator and DDU) Installation 
(Excluding KCM) 

EA 

$ 1,395.55 

1.05b 

2 

Onboard Equipment (validator and DDU) Commissioning 
(Excluding KCM) 

EA 

$ 206.50 

1.05c 

2 

Onboard Equipment (validator and DDU) Documentation 

EA 

$ 12,938.00 

1.06 

2 

Onboard Validator Equipment Installation, Commissioning, 
and Documentation (KCM Only) 

EA 

Not applicable 

1.07a 

2 

Wayside Validator Installation 

EA 

$ 1,545.79 

1.07b 

2 

Wayside Validator Commissioning 

EA 

$ 103.25 
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1.07c 

2 

Wayside Validator Documentation 

EA 

$ 12,938.00 

1.08a 

2 

VM Installation 

EA 

$4,239.96 

1.08b 

2 

VM Commissioning 

EA 

$ 206.50 

1.08c 

2 

VM Documentation 

EA 

$ 12,938.00 

1.09a 

2 

CST Installation 

EA 

$ 707.16 

1.09b 

2 

CST Commissioning 

EA 

$ 206.15 

$ 206.50 

1.09c 

2 

CST Documentation 

EA 

$12,938.00 


Testing 

1.10 

2 

Agency Test Facility Implementation, Housing, and 
Documentation 

LS 

$ 404,197.56 

1.11 

2 

Factory Testing and Documentation 

LS 

$ 378,976.92 

1.12 

2 

Integration Testing and Documentation 

LS 

$ 345,467.72 

1.13 

2 

Pilot Testing and Documentation 

LS 

$ 346,192.53 

1.14 

2 

System Acceptance Testing and Documentation 

LS 

$ 404,582.72 


Training 

1.15 

2 

Training Course Development Services 

LS 

$32,759.00 

1.16 

2 

Training Course Delivery and Materials 

EA 

$84,318.00 


Manuals 

1.17 

2 

System Manuals 

LS 

$ 145,005.78 


PRICE SECTION 2 - SYSTEM SOFTWARE DESIGN 


Item 

No. 

SOW 

Ref. 

Description and Model/Part Number or Product Name 

Uni 

t 

Unit Price 


Back Of 

ice Applications 

2.01 

6 

Account-based Transaction Processor 

LS 

$ 905,117.89 

2.02 

6 

Customer Relationship Management 

LS 

$ 1,292,571.72 

2.02a 

6 

Salesforce User - Tier 1 (1-99 users) 

EA 

$ 180.00 

2.02b 

6 

Salesforce User - Tier 2 (100+ users) 

EA 

$ 150.00 

2.03 

6 

Asset Incident Management 

LS 

$ 100,702.64 

2.04 

6 

System Manager 

LS 

$ 197,763.05 

2.05 

6 

Fare Media Management 

LS 

$ 61,247.94 

2.06 

6 

Financial Management 

LS 

$ 77/1,471.30 

$ 774,417.30 

2.06a 

6 

Sage 300c User-Tier 1 (1-14 users) 

EA 

$ 3,662.50 

2.06b 

6 

Sage 300c User - Tier 2 (15-25 users) 

EA 

$ 3,223.00 

2.06c 

6 

Sage 300c User - Tier 3 (26+ users) 

EA 

$ 2,760.00 

2.07 

6 

Central Payment 

LS 

$ 180,955.06 

2.08 

6 

Configuration and Change Management 

LS 

$ 104,630.00 

2.09 

6 

Tariff Management 

LS 

$ 37,119.32 

2.10 

6 

API Management 

LS 

$ 275,539.44 


Externa 

ly Sourced Applications 

2.11 

5 

Customer Mobile App 

LS 

$ 717,815.96 

2.12 

5 

Agency Mobile Apps (Fare Inspection & Fare Payment) 

LS 

$ 231,901.62 

2.13 

5 

Customer Website 

LS 

$ 367,257.90 


Field Device and Equipment Software 

2.14 

4 

Onboard and Wayside Validator Software 

LS 

$ 100,063.17 
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Item 

No. 

SOW 

Ref. 

Description and Model/Part Number or Product Name 

Uni 

t 

Unit Price 

2.15 

4 

Driver Display Unit Software 

LS 

$49,182.12 

2.16 

4 

Customer Service Terminal Software 

LS 

$ 136,953.24 

2.17 

4 

Full Feature Vending Machine Software 

LS 

$ 287,396.52 


API Development 

2.18 

3 

Application Programming Interface (API) Development 

LS 

$ 37,119.32 


System Integration Services 

2.19 

3 

Onboard Integration (PT, CT, KT, ET) 

LS 

$ 117,258.84 

2.20 

3 

Onboard Integration (KCM) 

LS 

$ 0.00 

2.21 

3 

Washington State Ferries Integration 

LS 

$ 63,607.28 

2.22 

3 

Data Access and Reporting Platform (DARe) Integration 

LS 

$ 146,449.36 

2.23 

3 

Retail Network Integration 

LS 

$ 107,978.76 

2.24 

3 

Integration with Legacy ORCA Back Office 

LS 

$ 46,398.40 

2.25 

3 

ADA Paratransit Integration 

LS 

$ 90,770.88 

2.26 

6 

Integration of Agency Provided CRM Application ($0 if Sl- 
provided CRM application is proposed) 

LS 

$ 0.00 

2.27 

6 

Integration of Agency Provided Financial Application ($0 if 
Sl-provided financial application is proposed) 

LS 

$ 0.00 

2.27a 

6 

Vanpool Integration 

LS 

$128,564.84 


Transit Payment Application 

2.28 

7 

Transit Payment Application 

LS 

$61,492.40 


PRICE SECTION 3 - EQUIPMENT AND SPARES 


Item 

No. 

SOW 

Ref. 

Description and Product Identity 

Unit 

Quantity for 
tiered price 

Unit Price 


Production Equipment 

3.02 

Tier 1 

4 

Onboard Validator (including spares) 
PROXmobil3 

EA 

1-10 

$ 2,025.18 

3.02 

Tier 2 

4 

Onboard Validator (including spares) 
PROXmobil3 

EA 

11-20 

$ 1,944.17 

3.02 

Tier 3 

4 

Onboard Validator (including spares) 
PROXmobil3 

EA 

21-50 

$ 1,782.15 

3.02 

Tier 4 

4 

Onboard Validator (including spares) 
PROXmobil3 

EA 

51-100 

$ 1,701.15 

3.02 

Tier 5 

4 

Onboard Validator (including spares) 
PROXmobil3 

EA 

100+ 

$ 1,620.14 

3.03 

4 

Onboard Validator Mounting System and 
Installation Kit (including spares) 

EA 

Not 

applicable 

$ 657.94 

3.04 

Tier 1 

4 

Driver Display Unit (including spares) 

TOUCHit3 

EA 

1-10 

$ 856.34 

3.04 

Tier 2 

4 

Driver Display Unit (including spares) 

TOUCHit3 

EA 

11-20 

$ 822.08 

3.04 

Tier 3 

4 

Driver Display Unit (including spares) 

TOUCHit3 

EA 

21-50 

$ 753.58 

3.04 

Tier 4 

4 

Driver Display Unit (including spares) 

TOUCHit3 

EA 

51-100 

$ 719.32 

3.04 

Tier 5 

4 

Driver Display Unit (including spares) 

TOUCHit3 

EA 

100+ 

$ 685.07 


RP 0119-17 Change Order 01 
























































Item 

No. 

SOW 

Ref. 

Description and Product Identity 

Unit 

Quantity for 
tiered price 

Unit Price 

3.05 

4 

Driver Display Unit Mounting System and 
Installation Kit (including spares) 

EA 

Not 

applicable 

$ 35^1.55 
$ 324.55 

3.06 

Tier 1 

4 

Wayside Validators (including spares) 
PROXmobil3 

EA 

1-10 

$ 1,884.44 

3.06 

Tier 2 

4 

Wayside Validators (including spares) 
PROXmobil3 

EA 

11-20 

$ 1,805.93 

3.06 

Tier 3 

4 

Wayside Validators (including spares) 
PROXmobil3 

EA 

21-50 

$ 1,727.41 

3.06 

Tier 4 

4 

Wayside Validators (including spares) 
PROXmobil3 

EA 

51-100 

$ 1,648.89 

3.06 

Tier 5 

4 

Wayside Validators (including spares) 
PROXmobil3 

EA 

100+ 

$ 1,570.37 

3.07 

4 

Wayside Validator System and Installation Kit 
(including spares) 

EA 

Not 

applicable 

$ 1,178.50 

3.08 

Tier 1 

4 

Customer Service Terminal (including spares, 
not including printer) 

EA 

1-10 

$ 6,392.00 

3.08 

Tier 2 

4 

Customer Service Terminal (including spares, 
not including printer) 

EA 

11-20 

$ 6,101.48 

3.08 

Tier 3 

4 

Customer Service Terminal (including spares, 
not including printer) 

EA 

21-50 

$ 5,810.93 

3.09 

4 

Customer Service Terminal Portable Printer 

EA 

Not 

applicable 

$ 2,659.50 

3.09a 

4 

Customer Service Terminal Standard Center 

Printer 

EA 

Not 

applicable 

$ 3,990.23 

3.10 

4 

Customer Service Terminal Mail Center Printer 

EA 

Not 

applicable 

$ 7,925.08 

3.11 

Tier 1 

4 

Full Feature Vending Machines (including 
spares) 

VENDstation 

EA 

1-2 

$ 67,273.70 

3.11 

Tier 2 

4 

Full Feature Vending Machines (including 
spares) 

VENDstation 

EA 

3-10 

$ 64,871.06 

3.11 

Tier 3 

4 

Full Feature Vending Machines (including 
spares) 

VENDstation 

EA 

11-20 

$ 57,663.17 

3.11 

Tier 4 

4 

Full Feature Vending Machines (including 
spares) 

VENDstation 

EA 

21-50 

$ 52,857.90 

3.11 

Tier 5 

4 

Full Feature Vending Machines (including 
spares) 

VENDstation 

EA 

51-100 

$ 50,455.27 

3.11 

Tier 6 

4 

Full Feature Vending Machines (including 
spares) 

VENDstation 

EA 

100+ 

$ 48,052.64 

3.11a 

4 

Credit for omission of bill and coin acceptance 

EA 

Not 

applicable 

($ 7,702.40) 

3.11b 

4 

Credit for omission of coin change issuance 

EA 

Not 

applicable 

($3,552.00) 

3.11c 

4 

Credit for omission of change issuance 

EA 

Not 

applicable 

($ 1,832.00) 


RP 0119-17 Change Order 01 




Item 

No. 

SOW 

Ref. 

Description and Product Identity 

Unit 

Quantity for 
tiered price 

Unit Price 

3.lid 

4 

Credit for omission of media issuance 

EA 

Not 

applicable 

($4,992.00) 

3.lie 

Tier 1 

4 

Light Feature Vending Machines 

VENDstation* 

EA 

1-2 

$ 51,326.63 

3.lie 

Tier 2 

4 

Light Feature Vending Machines 

VENDstation 

EA 

3-10 

$ 49,493.54 

3.lie 

Tier 3 

4 

Light Feature Vending Machines 

VENDstation 

EA 

11-20 

$43,994.26 

3.lie 

Tier 4 

4 

Light Feature Vending Machines 

VENDstation 

EA 

21-50 

$ 40,328.07 

3.lie 

Tier 5 

4 

Light Feature Vending Machines 

VENDstation 

EA 

51-100 

$ 38 ,>\ 9^1.97 
$ 38,497.07 

3.lie 

Tier 6 

4 

Light Feature Vending Machines 

VENDstation 

EA 

100+ 

$ 36,661.88 
$ 36,663.88 


Test Equipment 

3.12a 

2 

Test System with online applications of the 

IN IT Software listed in the EULA 

LS 

Not 

applicable 

$ 39,205.00 

3.12b 

2 

Vehicle BIB (including PROXmobile3, 

TOUCHit3, and mounting hardware) 

EA 

Not 

applicable 

$ 4,149.00 

3.12c 

2 

Onboard and Wayside Validator 

PROXmobile3 (including mounting hardware) 

EA 

Not 

applicable 

$ 1,659.60 

3.12d 

2 

Full Feature Vending Machine 

VENDstation 

EA 

Not 

applicable 

$ 50,787.99 

3.12e 

2 

Light Feature Vending Machine 

VENDstation 

EA 

Not 

applicable 

$ 35,858.09 

3.12f 

2 

Customer Service Terminal Test Unit 

EA 

Not 

applicable 

$ 12,573.19 


Training Equipment 

3.13 

Tier 1 

2 

On-board Validator Training Unit (BIB) - 
including PROXmobile3, TOUCHit3, mounting 
hardware and other SI equipment 

EA 

1-10 

$ 5,534.08 

3.13 

Tier 2 

2 

On-board Validator Training Unit (BIB) - 
including PROXmobile3, TOUCHit3, mounting 
hardware and other SI equipment 

EA 

11-20 

$4,812.24 

3.13 

Tier 3 

2 

On-board Validator Training Unit (BIB) - 
including PROXmobile3, TOUCHit3, mounting 
hardware and other SI equipment 

EA 

21-50 

$4,667.87 

3.14 

Tier 1 

2 

Wayside Validator Training Unit (BIB) - 
including PROXmobile3, and mounting 
hardware 

EA 

1-10 

$ 3,783.37 
$3,784.37 

3.14 

Tier 2 

2 

Wayside Validator Training Unit (BIB) - 
including PROXmobile3, and mounting 
hardware 

EA 

11-20 

$ 3,669.87 

3.14 

Tier 3 

2 

Wayside Validator Training Unit (BIB) - 
including PROXmobile3, and mounting 
hardware 

EA 

21-50 

$ 3,594.20 

3.15 

Tier 1 

2 

Customer Service Terminal Unit (BIB) 

EA 

1-10 

$ 13,204.04 


The Contactor's proposal erroneously named the Light Feature Vending Machine as VENDmobile, but the correct name is VENDstation. The functionality of 
the Light Feature Vending Machine described in the Contractor's proposal is correct and is what is priced here. 
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Item 

No. 

SOW 

Ref. 

Description and Product Identity 

Unit 

Quantity for 
tiered price 

Unit Price 

3.15 

Tier 2 

2 

Customer Service Terminal Unit (BIB) 

EA 

11-20 

$ 11,481.77 
$ 11,482.77 

3.15 

Tier 3 

2 

Customer Service Terminal Unit (BIB) 

EA 

21-50 

$ 11,137.32 


Spare Part Modules 

3.16 

Tier 1 

2 

customer display size 15", TOUCH 15" + 
controller, cables 

EA 

1-10 

$ 2,929.44 

3.16 

Tier 2 

2 

customer display size 15", TOUCH 15" + 
controller, cables 

EA 

11-20 

$ 2,796.28 

3.16 

Tier 3 

2 

customer display size 15", TOUCH 15" + 
controller, cables 

EA 

21+ 

$ 2,663.12 

3.17 

Tier 1 

2 

FEIG card reader for vending machine 

EA 

1-10 

$ 975.36 

3.17 

Tier 2 

2 

FEIG card reader for vending machine 

EA 

11-20 

$ 926.59 

3.17 

Tier 3 

2 

FEIG card reader for vending machine 

EA 

21+ 

$ 877.82 

3.18 

Tier 1 

2 

coin handling unit with change (6x carousel 
without hoppers) 

EA 

1-10 

$ 6,207.19 

3.18 

Tier 2 

2 

coin handling unit with change (6x carousel 
without hoppers) 

EA 

11-20 

$ 5,774.13 

3.18 

Tier 3 

2 

coin handling unit with change (6x carousel 
without hoppers) 

EA 

21+ 

$ 5,413.25 

3.19 

Tier 1 

2 

bill handling unit (MEI SCR) 

EA 

1-10 

$ 7,865.30 

3.19 

Tier 2 

2 

bill handling unit (MEI SCR) 

EA 

11-20 

$ 7,209.86 

3.19 

Tier 3 

2 

bill handling unit (MEI SCR) 

EA 

21+ 

$ 6,554.42 

3.20 

Tier 1 

2 

banknote vault (for 1400 notes) 

EA 

1-10 

$ 1,315.25 

3.20 

Tier 2 

2 

banknote vault (for 1400 notes) 

EA 

11-20 

$ 1,221.31 

3.20 

Tier 3 

2 

banknote vault (for 1400 notes) 

EA 

21+ 

$ 1,174.33 

3.21 

Tier 1 

2 

bank card processing unit 

EA 

1-10 

$4,369.61 

3.21 

Tier 2 

2 

bank card processing unit 

EA 

11-20 

$ 4,057.50 

3.21 

Tier 3 

2 

bank card processing unit 

EA 

21+ 

$ 3,901.44 

3.22 

Tier 1 

2 

1 x double printers (2 paper rolls in total) 

EA 

1-10 

$ 7,066.81 

3.22 

Tier 2 

2 

1 x double printers (2 paper rolls in total) 

EA 

11-20 

$ 6,796.58 

3.22 

Tier 3 

2 

1 x double printers (2 paper rolls in total) 

EA 

21+ 

$ 6,550.92 

3.23 

Tier 1 

2 

Smartcard dispenser 

EA 

1-10 

$4,726.98 
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Item 

No. 

SOW 

Ref. 

Description and Product Identity 

Unit 

Quantity for 
tiered price 

Unit Price 

3.23 

Tier 2 

2 

Smartcard dispenser 

EA 

11-20 

$4,361.81 

3.23 

Tier 3 

2 

Smartcard dispenser 

EA 

21+ 

$ 4,057.50 

3.24 

Tier 1 

2 

VENDstation board 

EA 

1-10 

$4,353.68 

3.24 

Tier 2 

2 

VENDstation board 

EA 

11-20 

$ 3,957.89 

3.24 

Tier 3 

2 

VENDstation board 

EA 

21+ 

$ 3,598.08 

3.25 

Tier 1 

2 

VENDstation extension board 

EA 

1-10 

$ 1,493.54 

3.25 

Tier 2 

2 

VENDstation extension board 

EA 

11-20 

$ 1,357.76 

3.25 

Tier 3 

2 

VENDstation extension board 

EA 

21+ 

$ 1,234.33 

3.26 

Tier 1 

2 

VENDstation power supply 

EA 

1-10 

$ 665.36 

3.26 

Tier 2 

2 

VENDstation power supply 

EA 

11-20 

$ 604.88 

3.26 

Tier 3 

2 

VENDstation power supply 

EA 

21+ 

$ 549.89 

3.27 

Tier 1 

2 

VENDstation Uninterruptible power supply 
(UPS) 

EA 

1-10 

$ 884.67 

3.27 

Tier 2 

2 

VENDstation Uninterruptible power supply 
(UPS) 

EA 

11-20 

$ 804.25 

3.27 

Tier 3 

2 

VENDstation Uninterruptible power supply 
(UPS) 

EA 

21+ 

$ 731.14 

3.28 

2 

HP Elite USB-C Dock 

EA 

Not 

applicable 

$ 296.64 

3.29 

2 

EP EliteDisplay E220t 21.5-inch touch monitor 

EA 

Not 

applicable 

$ 573.50 

3.30 

2 

Logitech 4K MK520 Wireless Keyboard and 
Mouse Combo 

EA 

Not 

applicable 

$ 118.66 

3.31 

2 

1NIT USB Card Reader 

EA 

Not 

applicable 

$ 395.52 

3.32 

2 

Logitech 4K Pro Web 

EA 

Not 

applicable 

$ 316.42 

3.33 

2 

Epson DS-1630 Flatbed Color Document 

Scanner 

EA 

Not 

applicable 

$ 593.50 

3.34 

2 

Epson DS-40 color portable scanner 

EA 

Not 

applicable 

$ 296.64 

3.35 

2 

MS-Cash Drawer (J-423-USB-M-B) 

EA 

Not 

applicable 

$ 296.64 

3.36 

2 

Igenico IPP350-11P1914A Payment Terminal 

EA 

Not 

applicable 

$ 741.60 

3.37 

2 

Epson C31CB25A8791 receipt printer with 
power supply 

EA 

Not 

applicable 

$ 1,255.78 

3.38 

2 

Brother Ruggedized RJ-4030 

EA 

Not 

applicable 

$ 1,186.56 
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Item 

No. 

SOW 

Ref. 

Description and Product Identity 

Unit 

Quantity for 
tiered price 

Unit Price 

3.39 

2 

Hewlett-Packard LV3000 Pole Display 7" Video 
with USB Connector, Dark Grey 

EA 

Not 

applicable 

$ 395.52 

3.40 

2 

TrippLite USB Hub 

EA 

Not 

applicable 

$ 148.32 

3.41 

2 

TrippLite UPS 500VA 280W UPS 

EA 

Not 

applicable 

$ 177.98 

3.42 

2 

Fargo HDP5600 ID Card Printer & Encoder 

EA 

Not 

applicable 

$4,885.29 

3.43 

2 

Fargo DTC1250e 

EA 

Not 

applicable 

$ 3,255.62 

3.44 

2 

Fargo HDP8500 ID Card Printer & Encoder 

EA 

Not 

applicable 

$ 9,702.60 

3.45 

Tier 1 

2 

coin vault 

EA 

1-10 

$ 1,282.23 

3.45 

Tier 2 

2 

coin vault 

EA 

11-20 

$ 1,165.67 

3.45 

Tier 3 

2 

coin vault 

EA 

21+ 

$ 1,059.70 

3.46 

Tier 1 

2 

coin hopper 

EA 

1-10 

$ 1,165.17 

3.46 

Tier 2 

2 

coin hopper 

EA 

11-20 

$ 1,059.25 

3.46 

Tier 2 

2 

coin hopper 

EA 

21+ 

$ 962.95 

3.47 

Tier 3 

2 

VENDstation Door Alarm 

EA 

1-10 

$ 58.08 

3.47 

Tier 3 

2 

VENDstation Door Alarm 

EA 

11-20 

$ 52.80 

3.47 

Tier 3 

2 

VENDstation Door Alarm 

EA 

21+ 

$ 48.00 

3.48 

Tier 4 

2 

MEI SCR Rebuild 

EA 

1-10 

$ 1,155.00 

3.48 

Tier 4 

2 

MEI SCR Rebuild 

EA 

11-20 

$ 1,339.80 

3.48 

Tier 4 

2 

MEI SCR Rebuild 

EA 

21+ 

$ 1,607.76 


PRICE SECTION 4 - FARE MEDIA 


Item 

No. 

SOW 

Ref. 

Description 

Uni 

t 

Unit Price 


Fare Media 

4.01 

7 

Contactless Extended-use Smart Cards (including training 
and test cards) 

EA 

$ 0.87 


PRICE SECTION 5 - OPERATIONS AND MAINTENANCE SUPPORT SERVICES (O&M) 


RP 0119-17 Change Order 01 





































Item No. 

SOW 

Ref. 

Description 

Unit 

Unit Price 

Year 1 O&M - Recurring Software License Renewals and Maintenance Fees 


Annual Software License Renewal & Maintenance Fee - Invoiced annually at the beginning of the 
license term 

5.01a 

8 

Oracle Enterprise Edition License with Advanced Security 

Maintenance Agreement 

(Renewal to Agreement in Attachment C) 

YR 

$ 316,800.00 


Annual Subscription Renewal - Invoiced annually at the beginning of the su 

iscription term 

5.01b 

8 

Shareplex Subscription Agreement 
(Renewal to Agreement in Attachment D) 

YR 

$ 129,999.60 


Monthly Software Maintenance - Invoiced monthly at the end of the maintenance term 

5.01c 

8 

IN IT Software Maintenance Agreement 
(Renewal to Agreement in Attachment B) 

MO 

$ 12,391.35 


Monthly Software License Renewal - Invoiced monthly at the end of the license term 

5.Old 

8 

IBM Maas 360 Mobile Device Management License 
Agreement 

(Renewal to Agreement in Attachment E) 

MO 

$ 960.00 

Year 2 O&M - Recurring Software Licenses and Maintenance 


Annual Software License & Maintenance - Invoiced annually at the beginning of the license term 

5.02a 

8 

Oracle Enterprise Edition License with Advanced Security 
Maintenance Agreement 
(Attachment C) 

YR 

$ 316,800.00 


Annual Subscription - Invoiced annually at the beginning of the subscription term 

5.02b 

8 

Shareplex Subscription Agreement 
(Attachment D) 

YR 

$ 129,999.60 


Monthly Software Maintenance - Invoiced monthly at the end of the maintenance term 

5.02c 

8 

IN IT Software Maintenance Agreement 
(Attachment B) 

MO 

$ 12,639.18 


Monthly Software License - Invoiced monthly at the end of the license term 

5.02d 

8 

IBM Maas 360 Mobile Device Management License 

Agreement 

(Attachment E) 

MO 

$ 960.00 

Year 3 O&M - Recurring Software Licenses and Maintenance 


Annual Software License & Maintenance - Invoiced annually at the beginning of the license term 

5.03a 

8 

Oracle Enterprise Edition License with Advanced Security 
Maintenance Agreement 
(Attachment C) 

YR 

$ 316,800.00 


Annual Subscription - Invoiced annually at the beginning of the subscription term 

5.03b 

8 

Shareplex Subscription Agreement 
(Attachment D) 

YR 

$ 129,999.60 


Monthly Software Maintenance - Invoiced monthly at the end of the maintenance term 

5.03c 

8 

IN IT Software Maintenance Agreement 
(Attachment B) 

MO 

$ 12,891.96 


Monthly Software License - Invoiced monthly at the end of the license term 

5.03d 

8 

IBM Maas 360 Mobile Device Management License 

Agreement 

(Attachment E) 

MO 

$ 960.00 
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Item No. 

SOW 

Ref. 

Description 

Unit 

Unit Price 

Year 4 O&M - Recurring Software Licenses and Maintenance 


Annual Software License & Maintenance - Invoiced annually at the beginning of the license term 

5.04a 

8 

Oracle Enterprise Edition License with Advanced Security 
Maintenance Agreement 
(Attachment C) 

YR 

$ 316,800.00 


Annual Subscription - Invoiced annually at the beginning of the subscription term 

5.04b 

8 

Shareplex Subscription Agreement 
(Attachment D) 

YR 

$ 129,999.60 


Monthly Software Maintenance - Invoiced monthly at the end of the maintenance term 

5.04c 

8 

IN IT Software Maintenance Agreement 
(Attachment B) 

MO 

$ 13,149.80 


Monthly Software License - Invoiced monthly at the end of the license term 

5.04d 

8 

IBM Maas 360 Mobile Device Management License 

Agreement 

(Attachment E) 

MO 

$ 960.00 

Year 5 O&M - Recurring Software Licenses and Maintenance 


Annual Software License & Maintenance - Invoiced annually at the beginning of the license term 

5.05a 

8 

Oracle Enterprise Edition License with Advanced Security 
Maintenance Agreement 
(Attachment C) 

YR 

$ 316,800.00 


Annual Subscription - Invoiced annually at the beginning of the subscription term 

5.05b 

8 

Shareplex Subscription Agreement 
(Attachment D) 

YR 

$ 129,999.60 


Monthly Software Maintenance - Invoiced monthly at the end of the maintenance term 

5.05c 

8 

IN IT Software Maintenance Agreement 
(Attachment B) 

MO 

$ 13,412.80 


Monthly Software License - Invoiced monthly at the end of the license term 

5.05d 

8 

IBM Maas 360 Mobile Device Management License 

Agreement 

(Attachment E) 

MO 

$ 960.00 

Year 6 O&M - Recurring Software Licenses and Maintenance 


Annual Software License & Maintenance - Invoiced annually at the beginning of the license term 

5.06a 

8 

Oracle Enterprise Edition License with Advanced Security 
Maintenance Agreement 
(Attachment C) 

YR 

$ 316,800.00 


Annual Subscription - Invoiced annually at the beginning of the subscription term 

5.06b 

8 

Shareplex Subscription Agreement 
(Attachment D) 

YR 

$ 129,999.60 


Monthly Software Maintenance - Invoiced monthly at the end of the maintenance term 

5.06c 

8 

IN IT Software Maintenance Agreement 
(Attachment B) 

MO 

$ 16,681.05 
$ 13,681.05 


Monthly Software License - Invoiced monthly at the end of the license term 

5.06d 

8 

IBM Maas 360 Mobile Device Management License 

Agreement 

(Attachment E) 

MO 

$ 960.00 

Year 7 O&M - Recurring Software Licenses and Maintenance 


Annual Software License & Maintenance - Invoiced annually at the beginning of the license term 

5.07a 

8 

Oracle Enterprise Edition License with Advanced Security 

YR 

$ 316,800.00 
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Item No. 

SOW 

Ref. 

Description 

Unit 

Unit Price 



Maintenance Agreement 
(Attachment C) 




Annual Subscription - Invoiced annually at the beginning of the subscription term 

5.07b 

8 

Shareplex Subscription Agreement 
(Attachment D) 

YR 

$ 129,999.60 


Monthly Software Maintenance - Invoiced monthly at the end of the maintenance term 

5.07c 

8 

IN IT Software Maintenance Agreement 
(Attachment B) 

MO 

$ 13,954.67 


Monthly Software License - Invoiced monthly at the end of the license term 

5.07d 

8 

IBM Maas 360 Mobile Device Management License 

Agreement 

(Attachment E) 

MO 

$ 960.00 

Year 8 O&M - Recurring Software Licenses and Maintenance 


Annual Software License & Maintenance - Invoiced annually at the beginning of the license term 

5.08a 

8 

Oracle Enterprise Edition License with Advanced Security 
Maintenance Agreement 
(Attachment C) 

YR 

$ 316,800.00 


Annual Subscription - Invoiced annually at the beginning of the subscription term 

5.08b 

8 

Shareplex Subscription Agreement 
(Attachment D) 

YR 

$ 129,999.60 


Monthly Software Maintenance - Invoiced monthly at the end of the maintenance term 

5.08c 

8 

IN IT Software Maintenance Agreement 
(Attachment B) 

MO 

$ 14,233.77 


Monthly Software License - Invoiced monthly at the end of the license term 

5.08d 

8 

IBM Maas 360 Mobile Device Management License 

Agreement 

(Attachment E) 

MO 

$ 960.00 

Year 9 O&M - Recurring Software Licenses and Maintenance 


Annual Software License & Maintenance - Invoiced annually at the beginning of the license term 

5.09a 

8 

Oracle Enterprise Edition License with Advanced Security 
Maintenance Agreement 
(Attachment C) 

YR 

$ 316,800.00 


Annual Subscription - Invoiced annually at the beginning of the subscription term 

5.09b 

8 

Shareplex Subscription Agreement 
(Attachment D) 

YR 

$ 129,999.60 


Monthly Software Maintenance - Invoiced monthly at the end of the maintenance term 

5.09c 

8 

IN IT Software Maintenance Agreement 
(Attachment B) 

MO 

$ 14,518.44 


Monthly Software License - Invoiced monthly at the end of the license term 

5.09d 

8 

IBM Maas 360 Mobile Device Management License 

Agreement 

(Attachment E) 

MO 

$ 960.00 

Year 10 O&M - Recurring Software Licenses and Maintenance 


Annual Software License & Maintenance - Invoiced annually at the beginning of the license term 

5.10a 

8 

Oracle Enterprise Edition License with Advanced Security 
Maintenance Agreement 
(Attachment C) 

YR 

$ 316,800.00 


Annual Subscription - Invoiced annually at the beginning of the subscription term 
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Item No. 

SOW 

Ref. 

Description 

Unit 

Unit Price 

5.10b 

8 

Shareplex Subscription Agreement 
(Attachment D) 

YR 

$ 129,999.60 


Monthly Software Maintenance - Invoiced monthly at the end of the maintenance term 

5.10c 

8 

IN IT Software Maintenance Agreement 
(Attachment B) 

MO 

$ 14,808.81 


Monthly Software License - Invoiced monthly at the end of the license term 

5.10d 

8 

IBM Maas 360 Mobile Device Management License 

Agreement 

(Attachment E) 

MO 

$ 960.00 

System Operations and Maintenance - Invoiced at the end of the service month 

5.12a 

8 

Year 1 - System Operations and Maintenance 

MO 

$ 68,863.28 

5.12b 

8 

Year 1 - Hardware Maintenance 

MO 

$ 56,398.66 

5.13a 

8 

Year 2 - System Operations and Maintenance 

MO 

$ 120,273.85 

513b 

8 

Year 2 - Hardware Maintenance 

MO 

$ 57,526.64 

5.14a 

8 

Year 3 - System Operations and Maintenance 

MO 

$ 123,252.92 

5.14b 

8 

Year 3 - Hardware Maintenance 

MO 

$ 58,677.17 

5.15a 

8 

Year 4 - System Operations and Maintenance 

MO 

$ 126,347.52 

5.15b 

8 

Year 5 - Hardware Maintenance 

MO 

$ 59,850.71 

5.16a 

8 

Year 5 - System Operations and Maintenance 

MO 

$ 129,565.00 

5.16b 

8 

Year 5 - Hardware Maintenance 

MO 

$ 61,047.73 

5.17a 

8 

Year 6 - System Operations and Maintenance 

MO 

$ 132,911.90 

5.17b 

8 

Year 6 - Hardware Maintenance 

MO 

$ 62,268.68 

5.18a 

8 

Year 7 - System Operations and Maintenance 

MO 

$ 136,395.18 

5.18b 

8 

Year 7 - Hardware Maintenance 

MO 

$ 63,514.06 

5.19a 

8 

Year 8 - System Operations and Maintenance 

MO 

$ 140,021.04 

5.19b 

8 

Year 8 - Hardware Maintenance 

MO 

$ 64,784.34 

5.20a 

8 

Year 9 - System Operations and Maintenance 

MO 

$ 143,799.75 

5.20b 

8 

Year 9 - Hardware Maintenance 

MO 

$ 66,080.02 

5.21a 

8 

Year 10 - System Operations and Maintenance 

MO 

$ 147,738.50 

5.21b 

8 

Year 10- Hardware Maintenance 

MO 

$ 67,401.62 

5.22a 

8 

Year 11 - System Operations and Maintenance 

MO 

$ 154,005.01 

5.22b 

8 

Year 11 - Hardware Maintenance 

MO 

$ 68,749.66 

Year 1 - System Hosting 

5.24a 

3&8 

Mobile Payment System hosting 

MO 

$ 3,063.00 

5.24b 

3&8 

IN IT Back Office, Test Facility, and Website hosting 

MO 

$ 71,492.60 

Year 2 - System Hosting 

5.25a 

3&8 

Mobile Payment System hosting 

MO 

$ 3,138.00 

5.25b 

3&8 

IN IT Back Office, Test Facility, and Website hosting 

MO 

$ 71,493.60 

Year 3 - System Hosting 

5.26a 

3&8 

Mobile Payment System hosting 

MO 

$ 3,215,88 

5.26b 

3&8 

IN IT Back Office, Test Facility, and Website hosting 

MO 

$ 71,494.60 

Year 4 - System Hosting 

5.27a 

3&8 

Mobile Payment System hosting 

MO 

$ 3,215.88 
$ 3,230.67 

5.27b 

3&8 

IN IT Back Office, Test Facility, and Website hosting 

MO 

$ 73,524.80 

Year 5 - System Hosting 
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Item No. 

SOW 

Ref. 

Description 

Unit 

Unit Price 

5.28a 

3&8 

Mobile Payment System hosting 

MO 

$ 3,311.44 

5.28b 

3&8 

IN IT Back Office, Test Facility, and Website hosting 

MO 

$ 73,524.80 

Year 6 - System Hosting 

5.29a 

3&8 

Mobile Payment System hosting 

MO 

$ 3,394.22 

5.29b 

3&8 

IN IT Back Office, Test Facility, and Website hosting 

MO 

$ 73,524.80 

Year 7 - System Hosting 

5.30a 

3&8 

Mobile Payment System hosting 

MO 

$ 3,479.08 

5.30b 

3&8 

IN IT Back Office, Test Facility, and Website hosting 

MO 

$ 77,201.00 

Year 8 - System Hosting 

5.31a 

3&8 

Mobile Payment System hosting 

MO 

$ 3,566.06 

5.31b 

3&8 

IN IT Back Office, Test Facility, and Website hosting 

MO 

$ 77,201.00 

Year 9 - System Hosting 

5.32a 

3&8 

Mobile Payment System hosting 

MO 

$ 3,655.21 

5.32b 

3&8 

IN IT Back Office, Test Facility, and Website hosting 

MO 

$ 77,201.00 

Year 10 - System Hosting 

5.33a 

3&8 

Mobile Payment System hosting 

MO 

$ 3,746.59 

5.33b 

3&8 

IN IT Back Office, Test Facility, and Website hosting 

MO 

$ 81,061.10 

Year 11 - System Hosting 

5.34a 

3&8 

Mobile Payment System hosting 

MO 

$ 3,566.06 

$ 3,840.25 

5.34b 

3&8 

IN IT Back Office, Test Facility, and Website hosting 

MO 

$ 81,061.10 

Year 12 - System Hosting 

5.35a 

3&8 

Mobile Payment System hosting 

MO 

$ 3,936.26 

5.35b 

3&8 

IN IT Back Office, Test Facility, and Website hosting 

MO 

$ 81,061.10 

Year 13 - System Hosting 

5.36a 

3&8 

Mobile Payment System hosting 

MO 

$ 4,034.67 

5.36b 

3&8 

IN IT Back Office, Test Facility, and Website hosting 

MO 

$ 85,114.10 

Software Escrow Services including cost for escrow company 

5.39 


Year 1 - Level 1 Software Escrow 

YR 

$ 25,968.00 

5.40 


Year 2 - Level 1 Software Escrow 

YR 

$ 25,968.00 

5.41 


Year 3 - Level 1 Software Escrow 

YR 

$ 25,968.00 

5.42 


Year 4 - Level 1 Software Escrow 

YR 

$ 25,968.00 

5.43 


Year 5 - Level 1 Software Escrow 

YR 

$ 25,968.00 

5.44 


Year 6 - Level 1 Software Escrow 

YR 

$ 25,968.00 

5.45 


Year 7 - Level 1 Software Escrow 

YR 

$ 25,968.00 

5.46 


Year 8 - Level 1 Software Escrow 

YR 

$ 25,968.00 

5.47 


Year 9 - Level 1 Software Escrow 

YR 

$ 25,968.00 

5.48 


Year 10- Level 1 Software Escrow 

YR 

$ 25,968.00 


PRICE SECTION 6 - SOFTWARE LICENSES 


Item 

No. 

SOW 

Ref. 

Description 

Uni 

t 

Unit Price 


Software Licenses and Subscriptions - Initial software license/subscription purchase - 
Invoiced in full at the time of purchase 
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Item 

No. 

SOW 

Ref. 

Description 

Uni 

t 

Unit Price 

6.01 

3 

Oracle Enterprise Edition with Advanced Security & 
Maintenance 

LS 

$ 2,440,540.00 

6.02 

3 

Shareplex Subscription & Professional Setup Services 

LS 

$ 313,234.20 

6.03 

3 

IBM Maas 360 Mobile Device Management 

LS 

$ 35,285.00 


HOURLY RATESt 

FOR CHANGES PER SECTION 1 ARTICLE 4 


Item 

No. 

Description 

Unit 

Unit Price 

AS.Ola 

Senior Project Manager 

HR 

$ 230.00 

AS.01b 

Project Manager 

HR 

$ 190.00 

AS.02 

Systems Engineer (Sr) 

HR 

$ 230.00 

AS.03 

Systems Engineer (Mid) 

HR 

$ 190.00 

AS.04 

Systems Engineer (Jr) 

HR 

$ 155.00 

AS.05 

Software Engineer (Sr) 

HR 

$ 230.00 

AS.06 

Software Engineer (Mid) 

HR 

$ 190.00 

AS.07 

Software Engineer (Jr) 

HR 

$ 155.00 

AS.08 

Technician 

HR 

$ 135.00 


END CONTRACT PRICING 


^ Agreed upon hourly rates (applicable to CY 2017) shall automatically adjust on an annual basis according to the BLS Consumer 
price index (CPI) from the end of the prior year. 
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Appendix - Resumes - ORCA 2ft 

>rca Table of Contents 

Project Executive & Western Regional Director.1 

2 Lead Project Engineer.3 

3 Lead Project Manager.5 

Information Technology Lead.8 

5 INIT-SQM Device Manufacturing.10 

INIT- TQA Cable Manufacturing.12 

7 Back Office Engineering.14 

8 Solutions Architect.16 

Systems Engineer.18 

10 Supply Chain and Installation Lead.19 

11 Financial Software Engineer.21 

CAPM, Associate Project Manager.23 

Quality Engineer.25 

14Configuration/Change Management Lead.28 

15 Training Lead.30 

16 Lead Hardware Engineer.32 

17 Field Devices Software Engineer.33 

18 Lead Mechanical Engineer.35 

19 Computer Systems Analyst/Database Systems Analyst.36 

20 1T . 

21 GO Systems and Solutions Business Analyst.41 

22H||^^H' Bytemark Project Manager.45 

23|^^^^^^B> Bytemark Project Coordinator.47 

24 Marathon Consulting Project Manager.50 

25 Marathon Consulting Sr. Web Developer.53 

26 Marathon Consulting Sr. Web Designer.56 

27 Marathon Consulting, Business Analyst.58 

28E-Bros Project Manager.65 

29E-Bros Designer/Front-end Developer.67 

Copyright © 2018 INIT ngORCA Resubmittal June 8, 2018 Page i 


All Personnel Information Should Be Treated Confidential 


































Appendix - Resumes - ORCA 

rca Table of Contents 



30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 


E-Bros Android Developer. 

|jpjj5jjii9 ' E-Bros Android Developer. 

ESP Services Operations Manager. 

^9 ESP Services Vice President. 

19- ESP Services Senior Project Manager. 

9. ESP Services Project Coordinator / Installation Manager.. 

99 Anthro-Tech, Inc. Principal Consultant. 

, Persistent Systems, Inc. Senior Architect - Salesforce.com 

9 Persistent Systems, Inc., SFDC Project Manager. 

|9> Persistent Systems, Inc., SFDC Technical Architect. 

^9H' Persistent Systems, Inc., Business Analyst. 

Babinec Consulting, LLC. 


69 

71 

73 

76 

78 

80 

84 

86 

92 

94 

97 

99 


The sections listed below contain trade secret information that provides a business advantage to 
INIT over competitors. These sections are proprietary and confidential and must not be 
disclosed except to agency employees directly concerned in evaluating INIT's response to RFP 
No. RTA/RP 0119-17 and third parties retained by the agency who have been retained to assist 
in the evaluation and then only to the extent they agree to abide by this limitation. 


CONFIDENTIAL SECTIONS: 

All Personal Information for Team Members and Reference Letters 
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SoundTransit 


PROPOSAL FORM NO. 2 CERTIFICATION REGARDING CONFLICT OF INTEREST 

The Proposer is required to certify that performance of the work will not create any conflicts of interest 
or disclose any actual or potential conflicts of interest by completing and signing one of the following 
statements: 


The Proposer hereby certifies that to the best of its knowledge and belief, performance of the 
services described in the Scope of Work will not create any conflicts of interest for the Proposer, 
any affiliates, any proposed subconsultants or key personnel of any of these organizations. 

DATE: 

AUTHORIZED SIGNATURE 

TITLE: Vice kJ<uaJ- jr C^O _ 

PROPOSER/COMPANY NAME: r TW IT Tn Adw^Lc/Wb /V- 'XrcAf fx \ 



OR 


The Proposer hereby discloses the following circumstances that could give rise to a conflict of 
interest for the Proposer, any affiliates, any proposed subconsultants or key personnel of any of 
these organizations. (Attach additional sheets as needed.) 

Name of Individual/Company to which potential conflict of interest might apply: 


Nature of potential conflict of interest: 


Proposed Remedy: 


DATE: _ 

AUTHORIZED SIGNATURE: 

TITLE: _ 

PROPOSER/COMPANY NAME: 
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SoundTransit 


PROPOSAL FORM NO. 3A DBE/SMALL BUSINESS COMMITMENT FORM - INSTRUCTIONS 

We affirm that we have read and understand the provisions in the Contract Documents setting forth the 
subcontracting and DBE and Small Business participation requirements established in this RFP and that we 
have complied with all such DBE/Small Business participation objectives. We certify that all documentation 
(including outreach information) submitted by us to demonstrate such compliance is true and accurate. 


Furthermore, we have listed on the following form all DBE/Small Businesses that we will use if awarded the 
Agreement under this RFP and whose participation will be counted toward meeting the applicable DBE/Small 
Business participation requirements. 


Definitions for DBE/Small Business Participation Plan 

Box 

Name 

Description 

1 

Procurement Number 

Sound Transit's Procurement Number as listed on the 
cover of the solicitation document. 

2 

Procurement Title 

Name of procurement as written on the cover of the 
solicitation document. 

3 

Company Name 

Proposer's company name. 

4 

Address 

Business address of Proposer's office in Sound 

Transit's locale. 

5 

City, State, Zip 

City, state, zip for Box No. 4 above. 

6 

Contact Name 

Proposer's contact person for this procurement. 

7 

Contact Phone 

Contact's phone number. 

8 

Contact's Email 

Contact's Email address. 

9 

DBE/Small Business Commitment 

Total percentage the Proposer commits to including on 
the contract of proposed subconsultants who are DBEs 
or certified or self-declared Small Businesses, 
including the Proposer’s contribution if Proposer is a 
DBE or certified or self-declared Small Business. 

10 

DBE/Small Business Goal 

Sound Transit's DBE/Small Business Goal as listed in 
the solicitation. 

11 

Total Proposal Price 

Total Amount of Proposal 

12 

DBE/Small Business Participants 

List all DBE/Small Business participants, including 
Proposer, if Proposer is a DBE or certified or self- 
declared Small Business. 

13 

Small Business Indicator 

Indicate the type of certification status or other 
indicator of each Small Business: Disadvantaged 
Business Enterprise (DBE), Minority Business 

Enterprise (MBE), Women Business Enterprise (WBE), 
Small Business Enterprise (SB), Small Business 
Administration (SBA), Americans With Disabilities Act 
Businesses (ADAB), Other (identify). 

14 

Description of Work 

Brief description of the work to be performed by the 
proposed DBE/Small Business participant. 
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PROPOSAL FORM NO. 3B DBE/SMALL BUSINESS COMMITMENT FORM 


Procurement No. 

Procurement Title 


1. RTA/RP 
0119-17 

Company Name 

3 IN IT, Innovations in Transportal 


Address 

4. 424 Network Station Road 

2. Systems 

City/State/Zip 

5. Chesapeake, VA, 23320 

Integrator for 
Next 

Generation 

Contact Name 

6. Mr. Jim Hicks 

Contact Phone 

7 . 757-413-9100 ext 314 

ORCA 

Contact Email 

8. JHicks@INITusa.com 


Diversity Contract Goals 

Small Business Commitment 

9. 

i % 

DBE Commitment 


14 % 

Small Business Goal 


5% 

DBE Goal 

10. 

2% 


11. Total Proposal Price 


$ 


48,291,783.01 


12. DBE/Small Business Participants 
(May include Proposer if counted 
towards Goal) 

13. Small 
Business 
Indicator 
(DBE, MBE, 
WBE, Size, etc.) 

14. Description of Work 

DBE/Small Business 
Participants 

15. Proposed 
Subcontract 
Amount 

16. Percent 
of 

Proposed 

Contract 

ESP Enterprises, Inc. 

DBE/MBE 

Vending Machine and Validator Installation Services 

$ 3,087,106.35 

636 % 

Anthro-Tech 

DBE/WBE 

User Experience Design Consulting 

$ 2,089,899.00 


i 3 i % 

West Sound Workforce 

DBE/WBE 

Customer Service Terminal Installation Services 

$ 22,960.00 

0.05 % 

Go Systems and Solutions 

DBE/WBE 

Business Analyst Consultant 

$ 339,600.00 

0.70 o/ 

/o 

Babinec Consulting 

DBE/WBE 

Technical Writing 

$ 460,000.00 

0.95 o /o 

Edco Incorporated 

DBE/WBE 

Contract Manufacturing 

$ 814,320.00 

1.68 o /o 

Subtotal and percent from attached list of DBE/Small Business participants: 

17.$ N/A 

18. N/A % 

(Please attach a separate list of additional planned DBE/Small 

Business participants, as necessary) DBE/Small Business Participants Total: 

19. $ 6,813,885.36 


20. 14 ' 11 % 










































SoundTransit 


PROPOSAL FORM NO. 4 DBE/SMALL BUSINESS OUTREACH DOCUMENTATION FORM 

Page 1 of 5 _ 


If there is a DBE or Small Business goal in this RFP, or if the Proposer will have subconsultants 
perform all or part of the Scope of Work, then the Proposer shall submit this form as part of its 
Proposal as documentation of its efforts to reach out to DBEs and Small Businesses to participate 
in the Agreement under this RFP. Sound Transit may request the Proposer provide additional 
information regarding its efforts. Attach additional forms as necessary. 

By submitting this Form, the Proposer certifies it contacted the identified DBEs and Small 
Businesses, in an effort to solicit their participation in performance of the work in the Agreement 
under this RFP. 


Is Subcontracting anticipated for this Contract? Yes Yes _No 


1. Firm Name: PH Traffic _ 

Contact Person: Pablo _ 

Area of Expertise: Civil and traffic engineering, traffic signal design, modifications, & ITS planning 

DBE and Small Business Status: DBE _ 

Date Contacted: October 17th _ 

Response: Not interested in installation services, sent names of firms that may but none DBE 


2. Firm Name: Premium Fleet Services 

Contact Person: Kim _ 

Area of Expertise: Truck/Fleet Maintenance and Service 

DBE and Small Business Status: MBE _ 

Date Contacted: October 17th _ 

Response: Not a good fit _ 


3. Firm Name: RPL Electric LLC _ 

Contact Person: Robbin Lane _ 

Area of Expertise: Electrical contracting on residential, commercial and industrial projects 

DBE and Small Business Status: WBE _ 

Date Contacted: October 17th _ 

Response: Unable to reach _ 


4. Firm Name: Sundance Electric _ 

Contact Person: Buzz _ 

Area of Expertise: Electrical contracting on commercial, industrial, and mass transit 

DBE and Small Business Status: DBE _ 

Date Contacted: October 17 _ 

Response: After review of website, thought not a good fit _ 
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PROPOSAL FORM NO. 4 DBE/SMALL BUSINESS OUTREACH DOCUMENTATION FORM 

Page 2 0 f 5 _ 

If there is a DBE or Small Business goal in this RFP, or if the Proposer will have subconsultants 
perform all or part of the Scope of Work, then the Proposer shall submit this form as part of its 
Proposal as documentation of its efforts to reach out to DBEs and Small Businesses to participate 
in the Agreement under this RFP. Sound Transit may request the Proposer provide additional 
information regarding its efforts. Attach additional forms as necessary. 

By submitting this Form, the Proposer certifies it contacted the identified DBEs and Small 
Businesses, in an effort to solicit their participation in performance of the work in the Agreement 
under this RFP. 


Is Subcontracting anticipated for this Contract? Yes Yes No 

1 . 

Firm Name: 

ESP Enterprises Inc. 


Contact Person: 

Steve Phelan 


Area of Expertise: 

Installation and maintenance of electronic fare-box equipment 


DBE and Small Business Status: MBE 


Date Contacted: 

September 12, 2017 


Response: 

Received quotation for vehicle and VM installation services 

2. 

Firm Name: 

Anthro-Tech 


Contact Person: 

Suzanne Boyd 


Area of Expertise: 

User-centered design consultancy focused on government agen 


DBE and Small Business Status: DBE/WBE 


Date Contacted: 

Several Conversations week of October 17 and 23rd 


Response: 

Received quotation for Web, mobile and software Apps 

3. 

Firm Name: 

Applexus Technologies LLC, 


Contact Person: 

Sam Mathew 


Area of Expertise: 

Information Technology Services and Consulting 


DBE and Small Business Status: MBE 


Date Contacted: 

October 17, 2017 


Response: 

Selected another company with similar services 

4. 

Firm Name: 

XITIJ 


Contact Person: 

Rajashree Varma 


Area of Expertise: 

Microsoft certified independent software vendor 


DBE and Small Business Status: MWBE 


Date Contacted: 

October 17, 2017 


Response: 

Selected another company with similar services 
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SoundTransit 


PROPOSAL FORM NO. 4 DBE/SMALL BUSINESS OUTREACH DOCUMENTATION FORM 

Page-?- of JL- 

If there is a DBE or Small Business goal in this RFP, or if the Proposer will have subconsultants 
perform all or part of the Scope of Work, then the Proposer shall submit this form as part of its 
Proposal as documentation of its efforts to reach out to DBEs and Small Businesses to participate 
in the Agreement under this RFP. Sound Transit may request the Proposer provide additional 
information regarding its efforts. Attach additional forms as necessary. 

By submitting this Form, the Proposer certifies it contacted the identified DBEs and Small 
Businesses, in an effort to solicit their participation in performance of the work in the Agreement 
under this RFP. 


Is Subcontracting anticipated for this Contract? YE ^ Yes 

No 

1 . 

Firm Name: 

Autoscan, Inc 



Contact Person: 

Cary Jenkins 



Area of Expertise: 

Computer Aided Design Services 



DBE and Small Business Status: MBE 



Date Contacted: 

October, 17, 2017 



Response: 

CAD Services are not needed 


2. 

Firm Name: 

Fair Cape Consulting, LLC 



Contact Person: 

Francesca Maier 



Area of Expertise: 

Computer Aided Design Services 



DBE and Small Business Status: DBE/WBE 



Date Contacted: 

October, 12, 2017 



Response: 

CAD Services are not needed 


3. 

Firm Name: 

ITEN Associates 



Contact Person: 

Biioy Nair 



Area of Expertise: 

Computer Aided Design Services 



DBE and Small Business Status: DBE/MBE 



Date Contacted: 

October, 18, 2017 



Response: 

CAD Services are not needed 


4. 

Firm Name: 

Keiser Group 



Contact Person: 

Janette Keiser 



Area of Expertise: 

Computer Aided Design Services 



DBE and Small Business Status: MWBE/DBE 



Date Contacted: 

October, 10, 2017 



Response: 

CAD Services are not needed 
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PROPOSAL FORM NO. 4 DBE/SMALL BUSINESS OUTREACH DOCUMENTATION FORM 

Page_4_of _5_ 

If there is a DBE or Small Business goal in this RFP, or if the Proposer will have subconsultants 
perform all or part of the Scope of Work, then the Proposer shall submit this form as part of its 
Proposal as documentation of its efforts to reach out to DBEs and Small Businesses to participate 
in the Agreement under this RFP. Sound Transit may request the Proposer provide additional 
information regarding its efforts. Attach additional forms as necessary. 

By submitting this Form, the Proposer certifies it contacted the identified DBEs and Small 
Businesses, in an effort to solicit their participation in performance of the work in the Agreement 
under this RFP. 


YES 

Is Subcontractinq anticipated for this Contract? Yes No 

i. 

Firm Name: 

Verity Cleaning Solutions 


Contact Person: 

Kristen Koplin 


Area of Expertise: 

Office Celaning 


DBE and Small Business Status: Not listed as DBE or WBE 


Date Contacted: 

October 16, 2017 


Response: 

Not a DBE registered company 

2. 

Firm Name: 

Paracletemc 


Contact Person: 

James Clark 


Area of Expertise: 

Security and Network Systems 


DBE and Small Business Status: DVOB 


Date Contacted: 

October 16, 2017 


Response: 

After review of services provided, determined to be not needed 

3. 

Firm Name: 

GO Systems and Solutions, LLC 


Contact Person: 

Paula Okunieff 


Area of Expertise: 

Transportation Technology Consulting 


DBE and Small Business Status: DBE/WBE 


Date Contacted: 

October 15, 2017 


Response: 

Awaiting quote 

4. 

Firm Name: 

Westsoundworkforce 


Contact Person: 

Julie Tappero 


Area of Expertise: 

Temporary Staffing Needs 


DBE and Small Business Status: DBE / WBE 


Date Contacted: 

October 10, 2017 


Response: 

Provided company information 
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PROPOSAL FORM NO. 4 DBE/SMALL BUSINESS OUTREACH DOCUMENTATION FORM 

Page_5_of _5_ 

If there is a DBE or Small Business goal in this RFP, or if the Proposer will have subconsultants 
perform all or part of the Scope of Work, then the Proposer shall submit this form as part of its 
Proposal as documentation of its efforts to reach out to DBEs and Small Businesses to participate 
in the Agreement under this RFP. Sound Transit may request the Proposer provide additional 
information regarding its efforts. Attach additional forms as necessary. 

By submitting this Form, the Proposer certifies it contacted the identified DBEs and Small 
Businesses, in an effort to solicit their participation in performance of the work in the Agreement 
under this RFP. 


YES 

Is Subcontractinq anticipated for this Contract? Yes No 

i. 

Firm Name: 

Edco Inc. 


Contact Person: 

Drew Elmquist 


Area of Expertise: 

Contract Manufacturing 


DBE and Small Business Status: DBE and WBE 


Date Contacted: 

March 6, 2018 


Response: 

After receiving a quote, have decided to utilize their services. 

2. 

Firm Name: 

Babinec Consulting 


Contact Person: 

Lisa Babinec 


Area of Expertise: 

Technical Writing 


DBE and Small Business Status: DBE and WBE 


Date Contacted: 

March 8, 2018 


Response: 

After receiving quote have decided to utilize their services 

3. 

Firm Name: 

Documents Design 


Contact Person: 

Barbara Hovater 


Area of Expertise: 

Technical Writing 


DBE and Small Business Status: DBE/WBE 


Date Contacted: 

March 8, 2018 


Response: 

Did not respond 

4. 

Firm Name: 

Mel Dodd Consulting 


Contact Person: 

Mel Dodd 


Area of Expertise: 

Technical Writing 


DBE and Small Business Status: DBE / MBE 


Date Contacted: 

March 8, 2018 


Response: 

Did not response 
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PROPOSAL FORM 5 CERTIFICATION OF BIDDER OR PROPOSER REGARDING 

DEBARMENT, SUSPENSION, AND OTHER RESPONSIBILITY MATTERS 

Instructions for Certification: 

By signing and submitting this form, the prospective lower tier participant 1 is providing the 

signed certification set out below, 

1. The certification in this clause is a material representation of fact upon which reliance was 
placed when this transaction was entered into. If it is later determined that the prospective 
lower tier participant knowingly rendered an erroneous certification, in addition to other 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies, including suspension and/or debarment. 

2. The prospective lower tier participant shall provide immediate written notice to Sound 
Transit if at any time the prospective lower tier participant learns that its certification was 
erroneous when submitted or has become erroneous by reason of changed circumstances. 

3. The terms "covered transaction," "debarred," "suspended," "ineligible," "lower tier covered 
transaction,” "participant," "persons," "lower tier covered transaction," "principal," 
"bid/proposal," and "voluntarily excluded," as used in this clause, have the meanings set out 
in the Definitions and Coverage sections of rules implementing Executive Order 12549 [49 
CFR Part 29], You may contact Sound Transit for assistance in obtaining a copy of those 
regulations. 

4. The prospective lower tier participant agrees by submitting this bid or proposal that, should 
the proposed covered transaction be entered into, it shall not knowingly enter into any lower 
tier covered transaction with a person who is proposed for debarment under 48 CFR part 9, 
subpart 9.4, debarred, suspended, declared ineligible, or voluntarily excluded from 
participation in this covered transaction, unless authorized in writing by Sound Transit. 

5. The prospective lower tier participant further agrees by submitting this bid or proposal that 
it will include the clause titled "Certification Regarding Debarment, Suspension, Ineligibility 
and Voluntary Exclusion - Lower Tier Covered Transaction", without modification, in all 
lower tier covered transactions and in all solicitations for lower tier covered transactions. 

6. A participant in a covered transaction may rely upon a certification of a prospective 
participant in a lower tier covered transaction that it is not proposed for debarment under 48 
CFR part 9, subpart 9.4, debarred, suspended, ineligible, or voluntarily excluded from the 
covered transaction, unless it knows that the certification is erroneous. A participant may 
decide the method and frequency by which it determines the eligibility of its principals. Each 
participant may, but is not required to, check the List of Parties Excluded from Federal 
Procurement and Nonprocurement Programs. 

7. Nothing contained in the foregoing shall be construed to require establishment of a system 
of records in order to render in good faith the certification required by this clause. The 
knowledge and information of a participant is not required to exceed that which is normally 
possessed by a prudent person in the ordinary course of business dealings. 

8. Except for transactions authorized under Paragraph 5 of these instructions, if a participant 
in a covered transaction knowingly enters into a lower tier covered transaction with a person 
who is proposed for debarment under 48 CFR part 9, subpart 9.4, suspended, debarred, 
ineligible, or voluntarily excluded from participation in this transaction, in addition to all 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies including suspension and/or debarment. 


1 “Lower tier participant” includes all contractors, consultants, subcontractors and subconsultants participating 
on any of Sound Transit’s contracts. 
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SoundTransit 


"Certification Regarding Debarment, Suspension, Ineligibility and Voluntary Exclusion" 

9. The prospective lower tier participant certifies, by submission of this bid or proposal, that 
neither it nor its "principals" [as defined at 49 C.F.R. § 29.105(p)] is presently debarred, 
suspended, proposed for debarment, declared ineligible, or voluntarily excluded from 
participation in this transaction by any Federal department or agency. 

10. When the prospective lower tier participant is unable to certify to any of the statements in 
this certification, such prospective participant shall attach an explanation to this bid or 
proposal. 


Proposer: "ff/IT fn/iov^ hnY\ c iV- 'Ircn^r+oJrirtA. 


By: 




(Type or Print Company Name) 


(Signature) 


\ff. +0*0 


(Title) 


Print Name: LaoJ o- Ke t'+k 
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PROPOSAL FORM 5 CERTIFICATION OF BIDDER OR PROPOSER REGARDING 

DEBARMENT, SUSPENSION, AND OTHER RESPONSIBILITY MATTERS 

Instructions for Certification: 

By signing and submitting this form, the prospective lower tier participant 1 is providing the 

signed certification set out below. 

1. The certification in this clause is a material representation of fact upon which reliance was 
placed when this transaction was entered into. If it is later determined that the prospective 
lower tier participant knowingly rendered an erroneous certification, in addition to other 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies, including suspension and/or debarment. 

2. The prospective lower tier participant shall provide immediate written notice to Sound 
Transit if at any time the prospective lower tier participant learns that its certification was 
erroneous when submitted or has become erroneous by reason of changed circumstances. 

3. The terms "covered transaction," "debarred,” "suspended," "ineligible," "lower tier covered 
transaction," "participant," "persons," "lower tier covered transaction," "principal," 
"bid/proposal," and "voluntarily excluded," as used in this clause, have the meanings set out 
in the Definitions and Coverage sections of rules implementing Executive Order 12549 [49 
CFR Part 29], You may contact Sound Transit for assistance in obtaining a copy of those 
regulations. 

4. The prospective lower tier participant agrees by submitting this bid or proposal that, should 
the proposed covered transaction be entered into, it shall not knowingly enter into any lower 
tier covered transaction with a person who is proposed for debarment under 48 CFR part 9, 
subpart 9.4, debarred, suspended, declared ineligible, or voluntarily excluded from 
participation in this covered transaction, unless authorized in writing by Sound Transit. 

5. The prospective lower tier participant further agrees by submitting this bid or proposal that 
it will include the clause titled "Certification Regarding Debarment, Suspension, Ineligibility 
and Voluntary Exclusion - Lower Tier Covered Transaction", without modification, in all 
lower tier covered transactions and in all solicitations for lower tier covered transactions. 

6. A participant in a covered transaction may rely upon a certification of a prospective 
participant in a lower tier covered transaction that it is not proposed for debarment under 48 
CFR part 9, subpart 9.4, debarred, suspended, ineligible, or voluntarily excluded from the 
covered transaction, unless it knows that the certification is erroneous. A participant may 
decide the method and frequency by which it determines the eligibility of its principals. Each 
participant may, but is not required to, check the List of Parties Excluded from Federal 
Procurement and Nonprocurement Programs. 

7. Nothing contained in the foregoing shall be construed to require establishment of a system 
of records in order to render in good faith the certification required by this clause. The 
knowledge and information of a participant is not required to exceed that which is normally 
possessed by a prudent person in the ordinary course of business dealings. 

8. Except for transactions authorized under Paragraph 5 of these instructions, if a participant 
in a covered transaction knowingly enters into a lower tier covered transaction with a person 
who is proposed for debarment under 48 CFR part 9, subpart 9.4, suspended, debarred, 
ineligible, or voluntarily excluded from participation in this transaction, in addition to all 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies including suspension and/or debarment. 


1 “Lower tier participant” includes all contractors, consultants, subcontractors and subconsultants participating 
on any of Sound Transit's contracts. 
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"Certification Regarding Debarment, Suspension, Ineligibility and Voluntary Exclusion" 

9. The prospective lower tier participant certifies, by submission of this bid or proposal, that 
neither it nor its "principals" [as defined at 49 C.F.R. § 29.105(p)] is presently debarred, 
suspended, proposed for debarment, declared ineligible, or voluntarily excluded from 
participation in this transaction by any Federal department or agency. 

10. When the prospective lower tier participant is unable to certify to any of the statements in 
this certification, such prospective participant shall attach an explanation to this bid or 
proposal. 


Proposer: GO Systems and Solutions LLC 

(Type or Print Company Name) 

By: F _ President 

(Signature) (Title) 

Print Name: Paula E - Okunieff 
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PROPOSAL FORM 5 CERTIFICATION OF BIDDER OR PROPOSER REGARDING 

DEBARMENT, SUSPENSION, AND OTHER RESPONSIBILITY MATTERS 

Instructions for Certification: 

By signing and submitting this form, the prospective lower tier participant 1 is providing the 

signed certification set out below. 

1. The certification in this clause is a material representation of fact upon which reliance was 
placed when this transaction was entered into. If it is later determined that the prospective 
lower tier participant knowingly rendered an erroneous certification, in addition to other 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies, including suspension and/or debarment. 

2. The prospective lower tier participant shall provide immediate written notice to Sound 
Transit if at any time the prospective lower tier participant learns that its certification was 
erroneous when submitted or has become erroneous by reason of changed circumstances. 

3. The terms "covered transaction," "debarred,” "suspended," "ineligible," "lower tier covered 
transaction," "participant," "persons," "lower tier covered transaction," "principal," 
"bid/proposal," and "voluntarily excluded," as used in this clause, have the meanings set out 
in the Definitions and Coverage sections of rules implementing Executive Order 12549 [49 
CFR Part 29], You may contact Sound Transit for assistance in obtaining a copy of those 
regulations. 

4. The prospective lower tier participant agrees by submitting this bid or proposal that, should 
the proposed covered transaction be entered into, it shall not knowingly enter into any lower 
tier covered transaction with a person who is proposed for debarment under 48 CFR part 9, 
subpart 9.4, debarred, suspended, declared ineligible, or voluntarily excluded from 
participation in this covered transaction, unless authorized in writing by Sound Transit. 

5. The prospective lower tier participant further agrees by submitting this bid or proposal that 
it will include the clause titled "Certification Regarding Debarment, Suspension, Ineligibility 
and Voluntary Exclusion - Lower Tier Covered Transaction", without modification, in all 
lower tier covered transactions and in all solicitations for lower tier covered transactions. 

6. A participant in a covered transaction may rely upon a certification of a prospective 
participant in a lower tier covered transaction that it is not proposed for debarment under 48 
CFR part 9, subpart 9.4, debarred, suspended, ineligible, or voluntarily excluded from the 
covered transaction, unless it knows that the certification is erroneous. A participant may 
decide the method and frequency by which it determines the eligibility of its principals. Each 
participant may, but is not required to, check the List of Parties Excluded from Federal 
Procurement and Nonprocurement Programs. 

7. Nothing contained in the foregoing shall be construed to require establishment of a system 
of records in order to render in good faith the certification required by this clause. The 
knowledge and information of a participant is not required to exceed that which is normally 
possessed by a prudent person in the ordinary course of business dealings. 

8. Except for transactions authorized under Paragraph 5 of these instructions, if a participant 
in a covered transaction knowingly enters into a lower tier covered transaction with a person 
who is proposed for debarment under 48 CFR part 9, subpart 9.4, suspended, debarred, 
ineligible, or voluntarily excluded from participation in this transaction, in addition to all 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies including suspension and/or debarment. 


1 “Lower tier participant” includes all contractors, consultants, subcontractors and subconsultants participating 
on any of Sound Transit's contracts. 
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"Certification Regarding Debarment, Suspension, Ineligibility and Voluntary Exclusion" 

9. The prospective lower tier participant certifies, by submission of this bid or proposal, that 
neither it nor its "principals" [as defined at 49 C.F.R. § 29.105(p)] is presently debarred, 
suspended, proposed for debarment, declared ineligible, or voluntarily excluded from 
participation in this transaction by any Federal department or agency. 

10. When the prospective lower tier participant is unable to certify to any of the statements in 
this certification, such prospective participant shall attach an explanation to this bid or 
proposal. 


Proposer: 


By: 


Print Name: 


Bytemark, Inc. 



(Type or Print Company Name) 


(Signat^fe) 
Micah Bergdale 




CEO & President 


(Title) 
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PROPOSAL FORM 5 CERTIFICATION OF BIDDER OR PROPOSER REGARDING 

DEBARMENT, SUSPENSION, AND OTHER RESPONSIBILITY MATTERS 

Instructions for Certification: 

By signing and submitting this form, the prospective lower tier participant 1 is providing the 

signed certification set out below. 

1. The certification in this clause is a material representation of fact upon which reliance was 
placed when this transaction was entered into. If it is later determined that the prospective 
lower tier participant knowingly rendered an erroneous certification, in addition to other 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies, including suspension and/or debarment. 

2. The prospective lower tier participant shall provide immediate written notice to Sound 
Transit if at any time the prospective lower tier participant learns that its certification was 
erroneous when submitted or has become erroneous by reason of changed circumstances. 

3. The terms “covered transaction, 1 ' "debarred," "suspended," "ineligible," "lower tier covered 
transaction," "participant," "persons," "lower tier covered transaction," "principal," 
"bid/proposal." and "voluntarily excluded," as used in this clause, have the meanings set out 
in the Definitions and Coverage sections of rules implementing Executive Order 12549 [49 
CFR Part 29]. You may contact Sound Transit for assistance in obtaining a copy of those 
regulations. 

4. The prospective lower tier participant agrees by submitting this bid or proposal that, should 
the proposed covered transaction be entered into, it shall not knowingly enter into any lower 
tier covered transaction with a person who is proposed for debarment under 48 CFR part 9, 
subpart 9.4, debarred, suspended, declared ineligible, or voluntarily excluded from 
participation in this covered transaction, unless authorized in writing by Sound Transit. 

5. The prospective lower tier participant further agrees by submitting this bid or proposal that 
it will include the clause titled "Certification Regarding Debarment, Suspension, Ineligibility 
and Voluntary Exclusion - Lower Tier Covered Transaction", without modification, in all 
lower tier covered transactions and in all solicitations for lower tier covered transactions. 

6. A participant in a covered transaction may rely upon a certification of a prospective 
participant in a lower tier covered transaction that it is not proposed for debarment under 48 
CFR part 9, subpart 9.4, debarred, suspended, ineligib’e, or voluntarily excluded from the 
covered transaction, unless it knows that the certification is erroneous. A participant may 
decide the method and frequency by which it determines the eligibility of its principals. Each 
participant may, but is not required to, check the List of Parties Excluded from Federal 
Procurement and Nonprocurement Programs. 

7. Nothing contained in the foregoing shall be construed to require establishment of a system 
of records in order to render in good faith the certification required by this clause. The 
knowledge and information of a participant is not required to exceed that which is normally 
possessed by a prudent person in the ordinary course of business dealings. 

8. Except for transactions authorized under Paragraph 5 of these instructions, if a participant 
in a covered transaction knowingly enters into a lower tier covered transaction with a person 
who is proposed for debarment under 48 CFR part 9, subpart 9.4, suspended, debarred, 
ineligible, or voluntarily excluded from participation in this transaction, in addition to all 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies including suspension and/or debarment. 


1 ‘Lower tier participant* includes all contractors, consultants, subcontractors and subconsultants participating 
on any of Sound Transit s contracts. 
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"Certification Regarding Debarment, Suspension, Ineligibility and Voluntary Exclusion" 

9. The prospective lower tier participant certifies, by submission of this bid or proposal, that 
neither it nor its "principals" [as defined at 49 C.F.R. § 29.105(p)] is presently debarred, 
suspended, proposed for debarment, declared ineligible, or voluntarily excluded from 
participation in this transaction by any Federal department or agency. 

10. When the prospective lower tier participant is unable to certify to any of the statements in 
this certification, such prospective participant shall attach an explanation to this bid or 
proposal. 



Page 29 

Please Prim on Recycled Psper 


Systems Integrator for next generation ORCA 


RFP No. RTA/RP 0119-17 
August 23, 2017 




SoundTransit 


PROPOSAL FORM 5 CERTIFICATION OF BIDDER OR PROPOSER REGARDING 

DEBARMENT, SUSPENSION, AND OTHER RESPONSIBILITY MATTERS 

Instructions for Certification: 

By signing and submitting this form, the prospective lower tier participant 1 is providing the 

signed certification set out below. 

1. The certification in this clause is a material representation of fact upon which reliance was 
placed when this transaction was entered into. If it is later determined that the prospective 
lower tier participant knowingly rendered an erroneous certification, in addition to other 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies, including suspension and/or debarment. 

2. The prospective lower tier participant shall provide immediate written notice to Sound 
Transit if at any time the prospective lower tier participant learns that its certification was 
erroneous when submitted or has become erroneous by reason of changed circumstances. 

3. The terms "covered transaction," "debarred," "suspended," "ineligible," "lower tier covered 
transaction," "participant," "persons," "lower tier covered transaction," "principal," 
"bid/proposal," and "voluntarily excluded," as used in this clause, have the meanings set out 
in the Definitions and Coverage sections of rules implementing Executive Order 12549 [49 
CFR Part 29]. You may contact Sound Transit for assistance in obtaining a copy of those 
regulations. 

4. The prospective lower tier participant agrees by submitting this bid or proposal that, should 
the proposed covered transaction be entered into, it shall not knowingly enter into any lower 
tier covered transaction with a person who is proposed for debarment under 48 CFR part 9, 
subpart 9.4, debarred, suspended, declared ineligible, or voluntarily excluded from 
participation in this covered transaction, unless authorized in writing by Sound Transit. 

5. The prospective lower tier participant further agrees by submitting this bid or proposal that 
it will include the clause titled "Certification Regarding Debarment, Suspension, Ineligibility 
and Voluntary Exclusion - Lower Tier Covered Transaction", without modification, in all 
lower tier covered transactions and in all solicitations for lower tier covered transactions. 

6. A participant in a covered transaction may rely upon a certification of a prospective 
participant in a lower tier covered transaction that it is not proposed for debarment under 48 
CFR part 9, subpart 9.4, debarred, suspended, ineligible, or voluntarily excluded from the 
covered transaction, unless it knows that the certification is erroneous. A participant may 
decide the method and frequency by which it determines the eligibility of its principals. Each 
participant may, but is not required to, check the List of Parties Excluded from Federal 
Procurement and Nonprocurement Programs. 

7. Nothing contained in the foregoing shall be construed to require establishment of a system 
of records in order to render in good faith the certification required by this clause. The 
knowledge and information of a participant is not required to exceed that which is normally 
possessed by a prudent person in the ordinary course of business dealings. 

8. Except for transactions authorized under Paragraph 5 of these instructions, if a participant 
in a covered transaction knowingly enters into a lower tier covered transaction with a person 
who is proposed for debarment under 48 CFR part 9, subpart 9.4, suspended, debarred, 
ineligible, or voluntarily excluded from participation in this transaction, in addition to all 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies including suspension and/or debarment. 
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SoundTransit 


"Certification Regarding Debarment, Suspension, Ineligibility and Voluntary Exclusion" 

9. The prospective lower tier participant certifies, by submission of this bid or proposal, that 
neither it nor its "principals" [as defined at 49 C.F.R. § 29.105(p)] is presently debarred, 
suspended, proposed for debarment, declared ineligible, or voluntarily excluded from 
participation in this transaction by any Federal department or agency. 


10. When the prospective lower tier participant is unable to certify to any of the statements in 
this certification, such prospective participant shall attach an explanation to this bid or 
proposal. 


Proposer: 


By: 


&p t-n /Qr /^(?s J- A) 


O 



(Type or Print Company Name) 


i ~f~ 


(Signature) 


Print Name: 




(Title) 
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PROPOSAL FORM 5 CERTIFICATION OF BIDDER OR PROPOSER REGARDING 

DEBARMENT, SUSPENSION, AND OTHER RESPONSIBILITY MATTERS 

Instructions for Certification: 

By signing and submitting this form, the prospective lower tier participant 1 is providing the 

signed certification set out below. 

1. The certification in this clause is a material representation of fact upon which reliance was 
placed when this transaction was entered into. If it is later determined that the prospective 
lower tier participant knowingly rendered an erroneous certification, in addition to other 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies, including suspension and/or debarment. 

2. The prospective lower tier participant shall provide immediate written notice to Sound 
Transit if at any time the prospective lower tier participant learns that its certification was 
erroneous when submitted or has become erroneous by reason of changed circumstances. 

3. The terms "covered transaction," "debarred," "suspended," "ineligible," "lower tier covered 
transaction,” "participant," "persons," "lower tier covered transaction," "principal," 
"bid/proposal," and "voluntarily excluded," as used in this clause, have the meanings set out 
in the Definitions and Coverage sections of rules implementing Executive Order 12549 [49 
CFR Part 29], You may contact Sound Transit for assistance in obtaining a copy of those 
regulations. 

4. The prospective lower tier participant agrees by submitting this bid or proposal that, should 
the proposed covered transaction be entered into, it shall not knowingly enter into any lower 
tier covered transaction with a person who is proposed for debarment under 48 CFR part 9, 
subpart 9.4, debarred, suspended, declared ineligible, or voluntarily excluded from 
participation in this covered transaction, unless authorized in writing by Sound Transit. 

5. The prospective lower tier participant further agrees by submitting this bid or proposal that 
it will include the clause titled "Certification Regarding Debarment, Suspension, Ineligibility 
and Voluntary Exclusion - Lower Tier Covered Transaction", without modification, in all 
lower tier covered transactions and in all solicitations for lower tier covered transactions. 

6. A participant in a covered transaction may rely upon a certification of a prospective 
participant in a lower tier covered transaction that it is not proposed for debarment under 48 
CFR part 9, subpart 9.4, debarred, suspended, ineligible, or voluntarily excluded from the 
covered transaction, unless it knows that the certification is erroneous. A participant may 
decide the method and frequency by which it determines the eligibility of its principals. Each 
participant may, but is not required to, check the List of Parties Excluded from Federal 
Procurement and Nonprocurement Programs. 

7. Nothing contained in the foregoing shall be construed to require establishment of a system 
of records in order to render in good faith the certification required by this clause. The 
knowledge and information of a participant is not required to exceed that which is normally 
possessed by a prudent person in the ordinary course of business dealings. 

8. Except for transactions authorized under Paragraph 5 of these instructions, if a participant 
in a covered transaction knowingly enters into a lower tier covered transaction with a person 
who is proposed for debarment under 48 CFR part 9, subpart 9.4, suspended, debarred, 
ineligible, or voluntarily excluded from participation in this transaction, in addition to all 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies including suspension and/or debarment. 


1 “Lower tier participant" includes all contractors, consultants, subcontractors and subconsultants participating 
on any of Sound Transit’s contracts. 
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"Certification Regarding Debarment, Suspension, Ineligibility and Voluntary Exclusion" 

9. The prospective lower tier participant certifies, by submission of this bid or proposal, that 
neither it nor its "principals" [as defined at 49 C.F.R, § 29.105(p)] is presently debarred, 
suspended, proposed for debarment, declared ineligible, or voluntarily excluded from 
participation in this transaction by any Federal department or agency. 

10. When the prospective lower tier participant is unable to certify to any of the statements in 
this certification, such prospective participant shall attach an explanation to this bid or 
proposal. 


Proposer: 
By: ___ 
Print Name 
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PROPOSAL FORM 5 CERTIFICATION OF BIDDER OR PROPOSER REGARDING 

DEBARMENT, SUSPENSION, AND OTHER RESPONSIBILITY MATTERS 

Instructions for Certification: 

By signing and submitting this form, the prospective lower tier participant 1 is providing the 

signed certification set out below. 

1. The certification in this clause is a material representation of fact upon which reliance was 
placed when this transaction was entered into. If it is later determined that the prospective 
lower tier participant knowingly rendered an erroneous certification, in addition to other 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies, including suspension and/or debarment. 

2. The prospective lower tier participant shall provide immediate written notice to Sound 
Transit if at any time the prospective lower tier participant learns that its certification was 
erroneous when submitted or has become erroneous by reason of changed circumstances. 

3. The terms "covered transaction," "debarred," "suspended," "ineligible," "lower tier covered 
transaction,” "participant," "persons," "lower tier covered transaction," "principal," 
"bid/proposal," and "voluntarily excluded," as used in this clause, have the meanings set out 
in the Definitions and Coverage sections of rules implementing Executive Order 12549 [49 
CFR Part 29]. You may contact Sound Transit for assistance in obtaining a copy of those 
regulations. 

4. The prospective lower tier participant agrees by submitting this bid or proposal that, should 
the proposed covered transaction be entered into, it shall not knowingly enter into any lower 
tier covered transaction with a person who is proposed for debarment under 48 CFR part 9, 
subpart 9.4, debarred, suspended, declared ineligible, or voluntarily excluded from 
participation in this covered transaction, unless authorized in writing by Sound Transit. 

5. The prospective lower tier participant further agrees by submitting this bid or proposal that 
it will include the clause titled "Certification Regarding Debarment, Suspension, Ineligibility 
and Voluntary Exclusion - Lower Tier Covered Transaction", without modification, in all 
lower tier covered transactions and in all solicitations for lower tier covered transactions. 

6. A participant in a covered transaction may rely upon a certification of a prospective 
participant in a lower tier covered transaction that it is not proposed for debarment under 48 
CFR part 9, subpart 9.4, debarred, suspended, ineligible, or voluntarily excluded from the 
covered transaction, unless it knows that the certification is erroneous. A participant may 
decide the method and frequency by which it determines the eligibility of its principals. Each 
participant may, but is not required to, check the List of Parties Excluded from Federal 
Procurement and Nonprocurement Programs. 

7. Nothing contained in the foregoing shall be construed to require establishment of a system 
of records in order to render in good faith the certification required by this clause. The 
knowledge and information of a participant is not required to exceed that which is normally 
possessed by a prudent person in the ordinary course of business dealings. 

8. Except for transactions authorized under Paragraph 5 of these instructions, if a participant 
in a covered transaction knowingly enters into a lower tier covered transaction with a person 
who is proposed for debarment under 48 CFR part 9, subpart 9.4, suspended, debarred, 
ineligible, or voluntarily excluded from participation in this transaction, in addition to all 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies including suspension and/or debarment. 


1 “Lower tier participant'' includes all contractors, consultants, subcontractors and subconsultants participating 
on any of Sound Transit’s contracts. 
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"Certification Regarding Debarment, Suspension, Ineligibility and Voluntary Exclusion" 

9. The prospective lower tier participant certifies, by submission of this bid or proposal, that 
neither it nor its "principals" [as defined at 49 C.F.R. § 29.105(p)] is presently debarred, 
suspended, proposed for debarment, declared ineligible, or voluntarily excluded from 
participation in this transaction by any Federal department or agency. 

10. When the prospective lower tier participant is unable to certify to any of the statements in 
this certification, such prospective participant shall attach an explanation to this bid or 
proposal. 


Proposer: 
By: _ 


UAB E-Bros 




LAliLL 


Print Name: 


ji -'(Signature) 

I V 


(Type or Print Company Name) 
_ Managing Director 


(Title) 


RICARDAS KUNEVICIUS 
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PROPOSAL FORM 5 CERI IFICAl ION OF BIDDER OR PROPOSER REGARDING 

DEBARMEN I, SUSPENSION, AND OTHER RESPONSIBILITY MATTERS 

Instructions for Certification: 

By signing and submitting this form, the prospective lower tier participant 1 is providing the 

signed certification set out below. 

1. The certification in this clause is a material representation of fact upon which reliance was 
placed when this transaction was entered into. If it is later determined that the prospective 
lower tier participant knowingly rendered an erroneous certification, in addition to other 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies, including suspension and/or debarment. 

2. The prospective lower tier participant shall provide immediate written notice to Sound 
Transit if at any time the prospective lower tier participant learns that its certification was 
erroneous when submitted or has become erroneous by reason of changed circumstances. 

3. The terms "covered transaction," "debarred,” "suspended," "ineligible," "lower tier covered 
transaction," "participant," "persons," "lower tier covered transaction," "principal," 
"bid/proposal," and "voluntarily excluded," as used in this clause, have the meanings set out 
in the Definitions and Coverage sections of rules implementing Executive Order 12549 [49 
CFR Part 29], You may contact Sound Transit for assistance in obtaining a copy of those 
regulations. 

4. The prospective lower tier participant agrees by submitting this bid or proposal that, should 
the proposed covered transaction be entered into, it shall not knowingly enter into any lower 
tier covered transaction with a person who is proposed for debarment under 48 CFR part 9, 
subpart 9.4, debarred, suspended, declared ineligible, or voluntarily excluded from 
participation in this covered transaction, unless authorized in writing by Sound Transit. 

5. The prospective lower tier participant further agrees by submitting this bid or proposal that 
it will include the clause titled "Certification Regarding Debarment, Suspension, Ineligibility 
and Voluntary Exclusion - Lower Tier Covered Transaction”, without modification, in all 
lower tier covered transactions and in all solicitations for lower tier covered transactions. 

6. A participant in a covered transaction may rely upon a certification of a prospective 
participant in a lower tier covered transaction that it is not proposed for debarment under 48 
CFR part 9, subpart 9.4, debarred, suspended, ineligible, or voluntarily excluded from the 
covered transaction, unless it knows that the certification is erroneous. A participant may 
decide the method and frequency by which it determines the eligibility of its principals. Each 
participant may, but is not required to, check the List of Parties Excluded from Federal 
Procurement and Nonprocurement Programs. 

7. Nothing contained in the foregoing shall be construed to require establishment of a system 
of records in order to render in good faith the certification required by this clause. The 
knowledge and information of a participant is not required to exceed that which is normally 
possessed by a prudent person in the ordinary course of business dealings. 

8. Except for transactions authorized under Paragraph 5 of these instructions, if a participant 
in a covered transaction knowingly enters into a lower tier covered transaction with a person 
who is proposed for debarment under 48 CFR part 9, subpart 9.4, suspended, debarred, 
ineligible, or voluntarily excluded from participation in this transaction, in addition to all' 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies including suspension and/or debarment. 


1 “Lower tier participant” includes all contractors, consultants, subcontractors and subconsultants participating 
on any of Sound Transit's contracts. 
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"Certification Regarding Debarment, Suspension, Ineligibility and Voluntary Exclusion" 

9. The prospective lower tier participant certifies, by submission of this bid or proposal, that 
neither it nor its "principals" [as defined at 49 C.F.R. § 29.105(p)] is presently debarred, 
suspended, proposed for debarment, declared ineligible, or voluntarily excluded from 
participation in this transaction by any Federal department or agency. 

10. When the prospective lower tier participant is unable to certify to any of the statements in 
this certification, such prospective participant shall attach an explanation to this bid or 
proposal. 


Proposer: iOp rc ^ 

(Type or Print Company Narine) 


By: 


Q -&1 Cx*. 


(Signatur^^ 


Pr-ei r- Cf Y) 

(Title) 


Print Name: 


^ ii*— I ' 


l # 94CL 
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PROPOSAL FORM 5 CERTIFICATION OF BIDDER OR PROPOSER REGARDING 

DEBARMENT, SUSPENSION, AND OTHER RESPONSIBILITY MATTERS 

Instructions for Certification: 

By signing and submitting this form, the prospective lower tier participant 1 is providing the 

signed certification set out below. 

1. The certification in this clause is a material representation of fact upon which reliance was 
placed when this transaction was entered into. If it is later determined that the prospective 
lower tier participant knowingly rendered an erroneous certification, in addition to other 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies, including suspension and/or debarment. 

2. The prospective lower tier participant shall provide immediate written notice to Sound 
Transit if at any time the prospective lower tier participant learns that its certification was 
erroneous when submitted or has become erroneous by reason of changed circumstances. 

3. The terms "covered transaction," "debarred," "suspended," "ineligible," "lower tier covered 
transaction,” "participant," "persons," "lower tier covered transaction," "principal," 
"bid/proposal," and "voluntarily excluded," as used in this clause, have the meanings set out 
in the Definitions and Coverage sections of rules implementing Executive Order 12549 [49 
CFR Part 29]. You may contact Sound Transit for assistance in obtaining a copy of those 
regulations. 

4. The prospective lower tier participant agrees by submitting this bid or proposal that, should 
the proposed covered transaction be entered into, it shall not knowingly enter into any lower 
tier covered transaction with a person who is proposed for debarment under 48 CFR part 9, 
subpart 9.4, debarred, suspended, declared ineligible, or voluntarily excluded from 
participation in this covered transaction, unless authorized in writing by Sound Transit. 

5. The prospective lower tier participant further agrees by submitting this bid or proposal that 
it will include the clause titled "Certification Regarding Debarment, Suspension, Ineligibility 
and Voluntary Exclusion - Lower Tier Covered Transaction", without modification, in all 
lower tier covered transactions and in all solicitations for lower tier covered transactions. 

6. A participant in a covered transaction may rely upon a certification of a prospective 
participant in a lower tier covered transaction that it is not proposed for debarment under 48 
CFR part 9, subpart 9.4, debarred, suspended, ineligible, or voluntarily excluded from the 
covered transaction, unless it knows that the certification is erroneous. A participant may 
decide the method and frequency by which it determines the eligibility of its principals. Each 
participant may, but is not required to, check the List of Parties Excluded from Federal 
Procurement and Nonprocurement Programs. 

7. Nothing contained in the foregoing shall be construed to require establishment of a system 
of records in order to render in good faith the certification required by this clause. The 
knowledge and information of a participant is not required to exceed that which is normally 
possessed by a prudent person in the ordinary course of business dealings. 

8. Except for transactions authorized under Paragraph 5 of these instructions, if a participant 
in a covered transaction knowingly enters into a lower tier covered transaction with a person 
who is proposed for debarment under 48 CFR part 9, subpart 9.4, suspended, debarred, 
ineligible, or voluntarily excluded from participation in this transaction, in addition to all 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies including suspension and/or debarment. 


1 "Lower tier participant” includes all contractors, consultants, subcontractors and subconsultants participating 
on any of Sound Transit's contracts. 
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"Certification Regarding Debarment, Suspension, Ineligibility and Voluntary Exclusion" 

9. The prospective lower tier participant certifies, by submission of this bid or proposal, that 
neither it nor its "principals" [as defined at 49 C.F.R. § 29.105(p)] is presently debarred, 
suspended, proposed for debarment, declared ineligible, or voluntarily excluded from 
participation in this transaction by any Federal department or agency. 

10. When the prospective lower tier participant is unable to certify to any of the statements in 
this certification, such prospective participant shall attach an explanation to this bid or 
proposal. 


Proposer: OJ \ € Cl\ A 0\ 0^1 j j , \f] C ■ l j 

Company Name) 

\a ce - 

(Signature) (Title) 

Print Name: Os c\c<nr~ _ 
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PROPOSAL FORM 5 CERTIFICATION OF BIDDER OR PROPOSER REGARDING 

DEBARMENT, SUSPENSION, AND OTHER RESPONSIBILITY MATTERS 

Instructions for Certification: 

By signing and submitting this form, the prospective lower tier participant 1 is providing the 

signed certification set out below. 

1. The certification in this clause is a material representation of fact upon which reliance was 
placed when this transaction was entered into. If it is later determined that the prospective 
lower tier participant knowingly rendered an erroneous certification, in addition to other 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies, including suspension and/or debarment. 

2. The prospective lower tier participant shall provide immediate written notice to Sound 
Transit if at any time the prospective lower tier participant leams that its certification was 
erroneous when submitted or has become erroneous by reason of changed circumstances. 

3. The terms "covered transaction," "debarred," "suspended," "ineligible," "lower tier covered 
transaction,” "participant," "persons," "lower tier covered transaction," "principal," 
"bid/proposal," and "voluntarily excluded," as used in this clause, have the meanings set out 
in the Definitions and Coverage sections of rules implementing Executive Order 12549 [49 
CFR Part 29]. You may contact Sound Transit for assistance in obtaining a copy of those 
regulations. 

4. The prospective lower tier participant agrees by submitting this bid or proposal that, should 
the proposed covered transaction be entered into, it shall not knowingly enter into any lower 
tier covered transaction with a person who is proposed for debarment under 48 CFR part 9, 
subpart 9.4, debarred, suspended, declared ineligible, or voluntarily excluded from 
participation in this covered transaction, unless authorized in writing by Sound Transit. 

5. The prospective lower tier participant further agrees by submitting this bid or proposal that 
it will include the clause titled "Certification Regarding Debarment, Suspension, Ineligibility 
and Voluntary Exclusion - Lower Tier Covered Transaction", without modification, in all 
lower tier covered transactions and in all solicitations for lower tier covered transactions. 

6. A participant in a covered transaction may rely upon a certification of a prospective 
participant in a lower tier covered transaction that it is not proposed for debarment under 48 
CFR part 9, subpart 9.4, debarred, suspended, ineligible, or voluntarily excluded from the 
covered transaction, unless it knows that the certification is erroneous. A participant may 
decide the method and frequency by which it determines the eligibility of its principals. Each 
participant may, but is not required to, check the List of Parties Excluded from Federal 
Procurement and Nonprocurement Programs. 

7. Nothing contained in the foregoing shall be construed to require establishment of a system 
of records in order to render in good faith the certification required by this clause. The 
knowledge and information of a participant is not required to exceed that which is normally 
possessed by a prudent person in the ordinary course of business dealings. 

8. Except for transactions authorized under Paragraph 5 of these instructions, if a participant 
in a covered transaction knowingly enters into a lower tier covered transaction with a person 
who is proposed for debarment under 48 CFR part 9, subpart 9.4, suspended, debarred, 
ineligible, or voluntarily excluded from participation in this transaction, in addition to all 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies including suspension and/or debarment. 


1 “Lower tier participant" includes all contractors, consultants, subcontractors and subconsultants participating 
on any of Sound Transit's contracts. 
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"Certification Regarding Debarment, Suspension, Ineligibility and Voluntary Exclusion" 

9. The prospective lower tier participant certifies, by submission of this bid or proposal, that 
neither it nor its "principals" [as defined at 49 C.F.R. § 29.105(p)] is presently debarred, 
suspended, proposed for debarment, declared ineligible, or voluntarily excluded from 
participation in this transaction by any Federal department or agency. 

10. When the prospective lower tier participant is unable to certify to any of the statements in 
this certification, such prospective participant shall attach an explanation to this bid or 
proposal. 
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PROPOSAL FORM 5 CERTIFICATION OF BIDDER OR PROPOSER REGARDING 

DEBARMENT, SUSPENSION, AND OTHER RESPONSIBILITY MATTERS 

Instructions for Certification: 

By signing and submitting this form, the prospective lower tier participant 1 is providing the 

signed certification set out below. 

1. The certification in this clause is a material representation of fact upon which reliance was 
placed when this transaction was entered into. If it is later determined that the prospective 
lower tier participant knowingly rendered an erroneous certification, in addition to other 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies, including suspension and/or debarment. 

2. The prospective lower tier participant shall provide immediate written notice to Sound 
Transit if at any time the prospective lower tier participant learns that its certification was 
erroneous when submitted or has become erroneous by reason of changed circumstances. 

3. The terms "covered transaction," "debarred," "suspended," "ineligible," "lower tier covered 
transaction," "participant," "persons," "lower tier covered transaction," "principal," 
"bid/proposal," and "voluntarily excluded," as used in this clause, have the meanings set out 
in the Definitions and Coverage sections of rules implementing Executive Order 12549 [49 
CFR Part 29]. You may contact Sound Transit for assistance in obtaining a copy of those 
regulations. 

4. The prospective lower tier participant agrees by submitting this bid or proposal that, should 
the proposed covered transaction be entered into, it shall not knowingly enter into any lower 
tier covered transaction with a person who is proposed for debarment under 48 CFR part 9, 
subpart 9.4, debarred, suspended, declared ineligible, or voluntarily excluded from 
participation in this covered transaction, unless authorized in writing by Sound Transit. 

5. The prospective lower tier participant further agrees by submitting this bid or proposal that 
it will include the clause titled "Certification Regarding Debarment, Suspension, Ineligibility 
and Voluntary Exclusion - Lower Tier Covered Transaction", without modification, in all 
lower tier covered transactions and in all solicitations for lower tier covered transactions. 

6. A participant in a covered transaction may rely upon a certification of a prospective 
participant in a lower tier covered transaction that it is not proposed for debarment under 48 
CFR part 9, subpart 9.4, debarred, suspended, ineligible, or voluntarily excluded from the 
covered transaction, unless it knows that the certification is erroneous. A participant may 
decide the method and frequency by which it determines the eligibility of its principals. Each 
participant may, but is not required to, check the List of Parties Excluded from Federal 
Procurement and Nonprocurement Programs. 

7. Nothing contained in the foregoing shall be construed to require establishment of a system 
of records in order to render in good faith the certification required by this clause. The 
knowledge and information of a participant is not required to exceed that which is normally 
possessed by a prudent person in the ordinary course of business dealings. 

8. Except for transactions authorized under Paragraph 5 of these instructions, if a participant 
in a covered transaction knowingly enters into a lower tier covered transaction with a person 
who is proposed for debarment under 48 CFR part 9, subpart 9.4, suspended, debarred, 
ineligible, or voluntarily excluded from participation in this transaction, in addition to all 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies including suspension and/or debarment. 


1 “Lower tier participant” includes all contractors, consultants, subcontractors and subconsultants participating 
on any of Sound Transit’s contracts. 
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"Certification Regarding Debarment, Suspension, Ineligibility and Voluntary Exclusion" 

9. The prospective lower tier participant certifies, by submission of this bid or proposal, that 
neither it nor its "principals" [as defined at 49 C.F.R. § 29.105(p)] is presently debarred, 
suspended, proposed for debarment, declared ineligible, or voluntarily excluded from 
participation in this transaction by any Federal department or agency. 

10. When the prospective lower tier participant is unable to certify to any of the statements in 
this certification, such prospective participant shall attach an explanation to this bid or 
proposal. 


Proposer: 



By: 



(Signature) _ f (Title) 

l- t SC /y /7~/~ 


Print Name: 
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PROPOSAL FORM 5 CERTIFICATION OF BIDDER OR PROPOSER REGARDING 

DEBARMENT, SUSPENSION, AND OTHER RESPONSIBILITY MATTERS 

Instructions for Certification: 

By signing and submitting this form, the prospective lower tier participant 1 is providing the 

signed certification set out below. 

1. The certification in this clause is a material representation of fact upon which reliance was 
placed when this transaction was entered into. If it is later determined that the prospective 
lower tier participant knowingly rendered an erroneous certification, in addition to other 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies, including suspension and/or debarment. 

2. The prospective lower tier participant shall provide immediate written notice to Sound 
Transit if at any time the prospective lower tier participant learns that its certification was 
erroneous when submitted or has become erroneous by reason of changed circumstances. 

3. The terms "covered transaction," "debarred,” "suspended," "ineligible," "lower tier covered 
transaction," "participant," "persons," "lower tier covered transaction," "principal," 
"bid/proposal," and "voluntarily excluded," as used in this clause, have the meanings set out 
in the Definitions and Coverage sections of rules implementing Executive Order 12549 [49 
CFR Part 29], You may contact Sound Transit for assistance in obtaining a copy of those 
regulations. 

4. The prospective lower tier participant agrees by submitting this bid or proposal that, should 
the proposed covered transaction be entered into, it shall not knowingly enter into any lower 
tier covered transaction with a person who is proposed for debarment under 48 CFR part 9, 
subpart 9.4, debarred, suspended, declared ineligible, or voluntarily excluded from 
participation in this covered transaction, unless authorized in writing by Sound Transit. 

5. The prospective lower tier participant further agrees by submitting this bid or proposal that 
it will include the clause titled "Certification Regarding Debarment, Suspension, Ineligibility 
and Voluntary Exclusion - Lower Tier Covered Transaction", without modification, in all 
lower tier covered transactions and in all solicitations for lower tier covered transactions. 

6. A participant in a covered transaction may rely upon a certification of a prospective 
participant in a lower tier covered transaction that it is not proposed for debarment under 48 
CFR part 9, subpart 9.4, debarred, suspended, ineligible, or voluntarily excluded from the 
covered transaction, unless it knows that the certification is erroneous. A participant may 
decide the method and frequency by which it determines the eligibility of its principals. Each 
participant may, but is not required to, check the List of Parties Excluded from Federal 
Procurement and Nonprocurement Programs. 

7. Nothing contained in the foregoing shall be construed to require establishment of a system 
of records in order to render in good faith the certification required by this clause. The 
knowledge and information of a participant is not required to exceed that which is normally 
possessed by a prudent person in the ordinary course of business dealings. 

8. Except for transactions authorized under Paragraph 5 of these instructions, if a participant 
in a covered transaction knowingly enters into a lower tier covered transaction with a person 
who is proposed for debarment under 48 CFR part 9, subpart 9.4, suspended, debarred, 
ineligible, or voluntarily excluded from participation in this transaction, in addition to all 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies including suspension and/or debarment. 


1 “Lower tier participant” includes all contractors, consultants, subcontractors and subconsultants participating 
on any of Sound Transit's contracts. 
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SoundTransit 


"Certification Regarding Debarment, Suspension, Ineligibility and Voluntary Exclusion" 

9. The prospective lower tier participant certifies, by submission of this bid or proposal, that 
neither it nor its "principals" [as defined at 49 C.F.R. § 29.105(p)] is presently debarred, 
suspended, proposed for debarment, declared ineligible, or voluntarily excluded from 
participation in this transaction by any Federal department or agency. 

10. When the prospective lower tier participant is unable to certify to any of the statements in 
this certification, such prospective participant shall attach an explanation to this bid or 
proposal. 


Proposer: 


By: 


Babinec Consulting LLC 


(Type or Print Company Name) 


Owner & CFO 


Print Name: 


(Signature) 

Lisa S. Babinec 


(Title) 
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PROPOSAL FORM 5 CERTIFICATION OF BIDDER OR PROPOSER REGARDING 

DEBARMENT, SUSPENSION, AND OTHER RESPONSIBILITY MATTERS 

Instructions for Certification: 

By signing and submitting this form, the prospective lower tier participant 1 is providing the 

signed certification set out below. 

1. The certification in this clause is a material representation of fact upon which reliance was 
placed when this transaction was entered into. If it is later determined that the prospective 
lower tier participant knowingly rendered an erroneous certification, in addition to other 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies, including suspension and/or debarment. 

2. The prospective lower tier participant shall provide immediate written notice to Sound 
Transit if at any time the prospective lower tier participant learns that its certification was 
erroneous when submitted or has become erroneous by reason of changed circumstances. 

3. The terms "covered transaction," "debarred," "suspended," "ineligible," "lower tier covered 
transaction,” "participant," "persons," "lower tier covered transaction," "principal," 
"bid/proposal," and "voluntarily excluded," as used in this clause, have the meanings set out 
in the Definitions and Coverage sections of rules implementing Executive Order 12549 [49 
CFR Part 29]. You may contact Sound Transit for assistance in obtaining a copy of those 
regulations. 

4. The prospective lower tier participant agrees by submitting this bid or proposal that, should 
the proposed covered transaction be entered into, it shall not knowingly enter into any lower 
tier covered transaction with a person who is proposed for debarment under 48 CFR part 9, 
subpart 9.4, debarred, suspended, declared ineligible, or voluntarily excluded from 
participation in this covered transaction, unless authorized in writing by Sound Transit. 

5. The prospective lower tier participant further agrees by submitting this bid or proposal that 
it will include the clause titled "Certification Regarding Debarment, Suspension, Ineligibility 
and Voluntary Exclusion - Lower Tier Covered Transaction", without modification, in all 
lower tier covered transactions and in all solicitations for lower tier covered transactions. 

6. A participant in a covered transaction may rely upon a certification of a prospective 
participant in a lower tier covered transaction that it is not proposed for debarment under 48 
CFR part 9, subpart 9.4, debarred, suspended, ineligible, or voluntarily excluded from the 
covered transaction, unless it knows that the certification is erroneous. A participant may 
decide the method and frequency by which it determines the eligibility of its principals. Each 
participant may, but is not required to, check the List of Parties Excluded from Federal 
Procurement and Nonprocurement Programs. 

7. Nothing contained in the foregoing shall be construed to require establishment of a system 
of records in order to render in good faith the certification required by this clause. The 
knowledge and information of a participant is not required to exceed that which is normally 
possessed by a prudent person in the ordinary course of business dealings. 

8. Except for transactions authorized under Paragraph 5 of these instructions, if a participant 
in a covered transaction knowingly enters into a lower tier covered transaction with a person 
who is proposed for debarment under 48 CFR part 9, subpart 9.4, suspended, debarred, 
ineligible, or voluntarily excluded from participation in this transaction, in addition to all 
remedies available to the Federal Government, Sound Transit may pursue available 
remedies including suspension and/or debarment. 

LA _ 

L..A. 


1 “Lower tier participant” includes all contractors, consultants, subcontractors and subconsultants participating 
on any of Sound Transit's contracts. 
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"Certification Regarding Debarment, Suspension, Ineligibility and Voluntary Exclusion" 

9. The prospective lower tier participant certifies, by submission of this bid or proposal, that 
neither it nor its ''principals" [as defined at 49 C.F.R. § 29.105(p)] is presently debarred, 
suspended, proposed for debarment, declared ineligible, or voluntarily excluded from 
participation in this transaction by any Federal department or agency. 

10. When the prospective lower tier participant is unable to certify to any of the statements in 
this certification, such prospective participant shall attach an explanation to this bid or 
proposal. 


Proposer: Persistent Systems Inc. 

(Type or Print Company Name) 

By: __ Account Owner 

(Signature) (Title) 

Print Name: Ranjan Juneja 
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SoundTransit 


PROPOSAL FORM NO. 6 CERTIFICATION REGARDING LOBBYING 

The undersigned [Consultant] certifies, to the best of his or her knowledge and belief, that: 

1. No Federal appropriated funds have been paid or will be paid, by or on behalf of the 
undersigned, to any person for influencing or attempting to influence an officer or employee 
of an agency, a Member of Congress, an officer or employee of Congress, or an employee 
of a Member of Congress in connection with the awarding of any Federal contract, the 
making of any Federal grant, the making of any Federal loan, the entering into of any 
cooperative agreement, and the extension, continuation, renewal, amendment, or 
modification of any Federal contract, grant, loan, or cooperative agreement. 

2. If any funds other than Federal appropriated funds have been paid or will be paid to any 
person for making lobbying contacts to an officer or employee of any agency, a Member of 
Congress, an officer or employee of Congress, or an employee of a Member of Congress 
in connection with this Federal contract, grant, loan, or cooperative agreement, the 
undersigned shall complete and submit Standard Form-LLL, "Disclosure Form to Report 
Lobbying," in accordance with its instructions [as amended by "Government wide Guidance 
for New Restrictions on Lobbying," 61 Fed. Reg. 1413 (1/19/96). Note: Language in 
paragraph (2) herein has been modified in accordance with Section 10 of the Lobbying 
Disclosure Act of 1995 (P.L. 104-65, to be codified at 2 U.S.C. 1601, et seq.)] 

3. The undersigned shall require that the language of this certification be included in the award 
documents for all subawards at all tiers (including subcontracts, subgrants, and contracts 
under grants, loans, and cooperative agreements) and that all subrecipients shall certify and 
disclose accordingly. 

This certification is a material representation of fact upon which reliance was placed when this 
transaction was made or entered into. Submission of this certification is a prerequisite for making or 
entering into this transaction imposed by 31, U.S.C. § 1352 (as amended by the Lobbying Disclosure 
Act of 1995). Any person who fails to file the required certification shall be subject to a civil penalty 
of not less than $10,000 and not more than $100,000 for each such failure. 

[Note: Pursuant to 31 U.S.C. § 1352(c)(1)-(2)(A), any person who makes a prohibited expenditure 
or fails to file or amend a required certification or disclosure form shall be subject to a civil penalty 
of not less than $10,000 and not more than $100,000 for each such expenditure or failure.] 

JJi/IT hin. 

The Consultant, JTnc. certifies or affirms the truthfulness and accuracy of each 

statement of its certification and disclosure, if any. In addition, the Consultant understands and 
agrees that the provisions of 31 U.S.C. 3801, et seq., apply to this certification and disclosure, if 
any. 

la/zr/n _ 

Signature of Consultant’s Authorized Official Date 

cx_ k , vr< cfo 

Name and Title of Consultant’s Authorized Official 
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SoundTransit 


PROPOSAL FORM NO. 7 BUY AMERICA 


Certification Requirement for Procurement of Steel, Iron, or Manufactured Products. 


Certificate of Compliance with Buy America Requirements 

The proposer or offeror hereby certifies that it will comply with the requirements of 49 U.S.C. 
5323(j)(1) and the applicable regulations in 49 CFR Part 661. 


Date 

Signature 





Attorney, Corporate Officer, Owner, or Partner 


Printed Name LlfiJa. Actf/? _ 

Company ^T^JCT £T'/>n< 3 Vc^l(/Vi) 1** < Trrw^ T>C . 

Title Vta» PrCMchuJ- ^ (L*Vs _ 


OR 


Certificate of Non-Compliance with Buy America Requirements 

The proposer or offeror hereby certifies that it cannot comply with the requirements of 49 U.S.C. 
53230) but it may qualify for an exception to the requirement pursuant to 49 U.S.C. 53230)(2), as 
amended, and the applicable regulations in 49 CFR Part 661.7. 

Date 

Signature 

Attorney, Corporate Officer, Owner, or Partner 


Printed Name 

Company 

Title 
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Capability 

Subsection 

Capability 

Type 

Capability 

Number 

Capability 

Fully Conforming 

Nonconforming 

Comments 

Section 2 Implementation Services 


Section 2.1 Project Management 


Project Management Plan 

Mandatory 

2.1.3-1 

The project Management Plan (PMP) will include but is not limited to the following elements: 

• Organization chart identifying key project personnel and contact information 

• Master schedule, identifying key project milestones and activities 

• Schedule for all project design and manufacturing elements that require Agency approval 

• Project meeting schedule 

• Methodology to control project schedule, scope, cost, and risk 

• Risk management plan and risk register, including identified project risks and actions required to mitigate them 

• Transition and change management processes and procedures 

• Safety processes and procedures 

• Quality assurance processes and procedures to confirm that the requirements of the contract are being met 

• Subcontractor management and communications 

• Document and Master Issues List (MIL) control processes and procedures, including version and traceability controls 

• Change management plan and procedures for all deliverables and subsequent revisions 

• Cost management 

X 



| Section 2.4 Testing 


CO i/l 

2 E 

Mandatory 

2.4.1-1 

All system components and subsystems will be tested individually and in integrated environments to make sure that 
they meet all technical and functional capabilities in the specifications. 

X 



S 1 

2.4.1-2 

All tests and inspections will be documented by the SI, and monitored and signed off by the Agencies or their 
representatives, as well as by the SI or its representatives. 

X 



c 

o 


2.4.2.1-1 

The inspection and test plan will include a detailed schedule indicating the sequence of each test, where and when each 
test will take place, and the number of Sl-provided staff covering each test. 

X 



Test 

Document; 

Mandatory 


The inspection and test plan will detail the number and range of tests, as well as the criteria for acceptance of each 
phase of testing. All performance measurement procedures and acceptance criteria, including the number and type of 
failures allowed in each phase of testing, will be subject to Agency review and approval. The plan will include all 
caoabilities as well as those identified during design review. 

X 



ro 

<D 

1— 

Mandatory 

2.4.3-1 

The test facility will be connected to the next generation ORCA back office test environment, including the account- 
based transaction processor and all specified support systems, which fully replicates the production environment. The 
test environment hardware will be identical to the production system hardware, but will not require system redundancy. 

X 



c 

<u 

< 



With the exception of factory testing, all specified formal testing will be conducted onsite, and all laboratory-based 
testing will be conducted in the test facility. The SI shall provide all labor and materials required for system testing, 
including but not limited to closed-looo fare media and bank cards. 

X 



J? 

0) 



First Article Configuration Inspection (FACI) will take place at the point of assembly, after manufacture or procurement of 
the first production units for each of the System components: onboard validators and mounting hardware, wayside 
validators and mounting hardware, driver display units and mounting hardware, vending machines, customer service 
terminals, and the back office, including all subsystems. 

X 



1— 

o 

Mandatory 

2.4.4.2-1 

Factory Acceptance Test (FAT) will be conducted by the SI at the Si's facility or at a subcontractor's facility designated by 
the SI. The SI shall provide all necessary supplies for FAT. 

X 



ro 



If at any time after any phase's test results have been approved, a design change is made, the performance of the 
modified system components will need to be demonstrated as conforming to this specification and the test results will 
be resubmitted for Agency approval. 

X 



c 


2.4.5.2-1 

The SI shall conduct all System Integration Test (SIT) testing at the Agency test facility. 

X 



ntegratio 

Testing 

Mandatory 


If the SI hosts the System, the automated failover process will be exercised in multiple failover scenarios during systems 
integration testing to demonstrate no data loss or significant degradation in system performance. The Disaster Recovery 
Plan will include regular failover testing after implementation. 

X 





2.4.5.3-1 

The SI will conduct all Field Integration Test (FIT) testing in the production environment. 

X 



c c w> 

t (C i 

s s. ts 

Mandatory 

2.4. 6. 1-1 

SAT will be performed in the production environment with all components, subsystems, and networks completely 
operational, online, and in service. 

X 



g £ 

- £ 0, 

2.4.6.2-1 

The SI shall submit a request for Final System Acceptance upon successful completion of SAT and determination that all 
work has been completed in accordance with this Scope of Work and final design. 

X 






















Capability 

Subsection 

Capability 

Type 

Capability 

Number 

Capability 

Fully Conforming 

NonConforming 

Comments 

Section 8 Operation & Maintenance Services 


Section 8.2 Operations & Maintenance Model 


Operations & Maintenance Model 

Mandatory 

8.2-1 

The SI shall warrant that all of the equipment, computer systems, and software provided for the System, including those 
components warranted by third-party suppliers, will be free from defects in operation, material, and workmanship under 
normal operating use. Remedial work to correct deficiencies will include the repair or replacement of equipment, 
comDonents. devices and/or materials. 

X 



8.2-2 

The SI shall provide a one (1) year warranty that begins upon Final System Acceptance. 

X 



8.2-3 

The SI shall follow proper Agency security procedures for gaining access to field equipment and facilities, and shall not 
engage in such procedures without having received Agency-provided training. 

X 



8.2-4 

Prior to the start of the SMA, all software maintenance activities will be covered under warranty. 

X 



Desired 

8.2-5 

All software maintenance performed under the warranty will comply with the documented software maintenance 
capabilities 

X 



8.2-6 

The warranty will include but is not necessarily limited to the following SI provided equipment and software, and back 
office systems and software: 

• Onboard validators and associated hardware 

• Wayside validators and associated hardware 

• DDUs and associated hardware 

• CSTs 

• VMs 

• Test facility 

• Production and test back office systems 

X 



8.2-7 

The warranty will cover the following: 

• Repair or replacement of all equipment or systems required as a result of an identified hardware defect 

• Software updates or re-writes required to repair all identified software defects or bugs, and apply all necessary patches 
or security updates released by the SI or third-party software providers throughout the term of the warranty 

• All labor associated with hardware and software testing and deployment, both in the lab and field environments, 
needed to support warranty activities 

X 



8.2-8 

If during the warranty term, the required replacement of any component or device exceeds 10% of the mean quantity 
installed, a "fleet defect" will be declared, and the entire quantity of such components or devices will be considered 
defective. 

X 



8.2-9 

If a fleet defect is declared, the Program needs the SI to undertake and complete a corrective work program to replace all 
components of that type with new components. The repair schedule and procedures will be subject to Agency review 
and approval. All items replaced under these terms will be warranted for at least one (1) year after replacement. 

X 



8.2-10 

A fleet defect will be considered resolved when the installed components are determined to meet or exceed all of the 

KPI capabilities, and upon Agency approval. 

X 



8.2-11 

The Program needs the SI to be responsible for all personnel, labor, tools, materials, shipping charges, and other costs 
associated with the repair or replacement of components and/or subsystems throughout the warranty term. 


X 

INIT will train Sound Transit, and provide spares of internal components which are designed to be 
field serviceable, including swapping out components at the installed locations. If any first line 
maintenance issues arise, INIT will provide remote technical support. Second line maintenance will be 
provided by INIT. 

INIT will not be reimbursing ngORCA/ROOT for their costs in providing the first line maintenance. 

To clarify the RFP's section 8.12.2.5 titled Incident Response Times, INIT expects that vending 
machine first level maintenance will be handled by ROOT (specifically Sound Transit) as described in 
section 8.1 of the RFP. 

8.2-12 

Following completion of the warranty term, should there be warranty work to complete, the warranty will be extended 
to provide equal coverage for each piece of equipment. 

X 



8.2-13 

The warranty will not apply to any equipment that has been damaged by any person other than the SI or Si's assignee. 
Environmental conditions described in these technical specifications will be considered normal operating conditions for 
this Svstem and will not aualifv for exclusion. 

X 


































Capability 

Subsection 

Capability 

Type 

Capability 

Number 

Capability 

Fully Conforming 

Nonconforming 

Comments 



8.2-14 

The Agencies will operate and maintain the equipment and software in accordance with the Si's specific instructions in 
order to maintain this warranty. The Agencies will be held blameless if the SI has provided inadequate or inaccurate 
training, and/or incomplete operating manuals, maintenance manuals, electrical and electronic schematics, mechanical 
diagrams, or software documentation. 

X 



8.2-15 

In the event the SI fails to comply promptly with warranty requirements, the Agencies will, upon written notice to the SI, 
have the right to deduct the cost of the Agencies' prevailing labor and material costs for repairing a defect from any 
compensation due, or coming due, to the SI. In the event the SI has been paid in full, the Program needs the SI to agree 
to comoensate the Agencies for the costs incurred. 

X 



8.2-16 

Spare modules used by the SI during the warranty term will be replaced by the SI at no cost to the Agencies. The Program 
needs the SI to maintain sufficient spare sub-assemblies, modules, and components to meet the System availability 
caoabilities through the conclusion of the warrantv. 

X 



8.2-17 

During the entire warranty term, any and all repairs, adjustments, or replacements of equipment by the Program needs 
the SI to be documented by the SI within the AIM at the completion of every day. 

X 



8.2-18 

The Program needs the SI to develop a warranty plan outlining processes and procedures to be implemented to meet all 
specified warranty requirements. A draft of the warranty plan will be submitted at FDR and a final version will be 
orovided a minimum of 90 calendar davs prior to the start of anv warrantv term. 

X 



8.2-19 

The Program needs the SI to provide a new component or subsystem if a particular component or subsystem was 
repaired or replaced three (3) times for the same failure, as determined bv the FRB, within the warrantv period. 

X 



Section 8.3 Website Hosting 



Mandatory 

8.3-1 

The SI shall provide the hosting services necessary to support website operations, and interfaces to internal and external 
systems needed to perform the required functions for the duration of the contract. 

X 



Section 8.4 Back Office Hosting 



Mandatory 

8.4-1 

If the SI hosts the System, they shall provide the hosting services necessary to support system operations and interfaces 
to internal and external systems needed to perform the required functions for the duration of the contract. 

X 



Section 8.5 Back Office Operations 


Back Office Operations 

Mandatory 

8.5-1 

The SI shall be responsible for all back office operations and maintenance under the back office operations agreement. 

X 



8.5-2 

Throughout the term of the back office operations agreement, the SI will meet the associated system performance 
capabilities (e.g., back office accuracy, availability, and server authorization rate). 

X 



8.5-3 

The SI shall develop a back office operations plan outlining the processes and procedures to be implemented in order to 
meet all specified back office operations capabilities. A draft of the back office operations plan will be submitted at FDR 
and a final version will be provided a minimum of 90 days prior to the start of the back office operations agreement 

term. 

X 



Desired 

8.5-4 

The Si's Lead Engineer will continue in a full-time onsite operations and maintenance services role throughout the term 
of the back office operations agreement. The SI may propose an alternate to fill the primary onsite operations 
management role, subject to Agency approval, and may elect to have additional onsite staff as needed to meet the 
caoabilities of the back office operations agreement. 

X 



8.5-5 

The Program needs the SI to allow Agency staff to shadow all back office operations and support activities throughout 
the back office operations agreement. 

X 



8.5-6 

Under the back office operations agreement, the Program needs the SI to be responsible for the following activities: 

• Monitoring system performance and health 

• Providing timely and accurate processing of transactions 

• Overseeing operation of all back office support systems (e.g., CRM application and financial management systems) 

• Overseeing website operation 

• Overseeing operation and updates of mobile apps 

• Maintaining system configuration, and making configuration changes upon request from the Agencies 

• Testing and deployment of website and configuration changes 

• Supporting report updates and ad-hoc data requests 

X 



8.5-7 

Failure to meet the specified performance capabilities will result in deductions from the monthly back office operations 
payments made to the SI. Deductions will be based on the level of performance, and impacts of persistent failures. 

X 



8.5-8 

The Program needs the SI to be responsible for updates to the Sl-provided reports no less than quarterly. 

X 
















































Capability 

Subsection 

Capability 

Type 

Capability 

Number 

Capability 

Fully Conforming 

Nonconforming 

Comments 



8.5-9 

The SI will provide a monthly invoice (at end of month) for back office, online services and other components in an 
itemized fashion with any credits related to KPIs also listed. 

X 



Section 8.6 ISMS Compliance 
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Mandatory 

8.6-1 

The SI shall be responsible for maintaining the System's compliance with all required security controls, and for facilitating 
the operation of the regional ISMS by providing all necessary evidence of proper control implementation and operation 
for the Svstem for the duration of the contract. 

X 
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Desired 

H 

The region's ISMS will continuously assess the risk profile of the System. If needed, the Program needs the SI to 
implement additional controls to address newly identified risks to the System, based on changing technological, 
business, or comoliance needs. 

X 



Section 8.7 Software Maintenance 




3 i 

The SI shall provide preventative and corrective software maintenance to support system operations while meeting the 
performance standards set forth in this SOW. 

X 




Mandatory 

8.7.1-2 

The SI shall submit a Software Maintenance Plan for review and approval identifying the approach to meeting the 
capabilities of the SMA. 

X 





8.7.1-3 

Throughout the term of the SMA, the SI will meet the associated system performance capabilities (e.g., device reliability 
and accuracy). 

X 





8.7.1-4 

The Software Maintenance Plan will cover the following: 

• Software updates or re-writes required to fix all identified software defects or bugs throughout the term of the SMA 

• Application of all necessary patches or security updates released by the SI or third-party software providers 

• All software testing and deployment, both in the lab and field environments, needed to support these activities 

X 
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8.7.1-5 

Performance of software maintenance activities will be completed in a manner that does not disrupt or degrade system 
operations, to the fullest extent possible. 

X 
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Desired 

8.7.1-6 

The Program needs the SI to make corrections and modifications to the System software in coordination with the Agency 
staff. Serious issues (i.e., any error which causes system reliability or availability to fall below stated capabilities) will be 
corrected immediatelv. 

X 



8.7.1-7 

If the condition requiring correction affects the operation of other system components, then the Program needs the SI to 
provide repair or replacement of the System components that fail, regardless of whether the warranty term has expired 
for those comoonents. 

X 





8.7.1-8 

The Program needs the SI to make every attempt to fix software problems impacting revenue collection within two (2) 
hours of being reported. 

X 





8.7.1-9 

The SI and the Agencies shall agree on an appropriate course of action if a third-party software provider goes out of 
business, or if maintenance updates for third-party software degrades performance of the Si's system. 

X 





8.7.1-10 

Software to be maintained under the SMA will include all required updates to the APIs and associated specifications 
provided by the SI. 

X 





8.7.1-11 

All third-party software will be maintained at the most current or previous version at no additional charge throughout 
the term of the SMA, so long as it does not involve a major rewrite of the Si's software. 

X 




Mandatory 

8.7.2-1 

The SI shall provide technical support to the Agencies for the general use and operation of the software via telephone 
throughout the warranty and SMA terms. Telephone support will be provided by the SI during normal business hours 
(PST) Mondav through Fridav. excluding holidavs. 

X 





mm 

The SI shall provide phone number and email address for the reporting of software defects or malfunctions, and system 
outages, 24 hours a day, seven (7) days a week. 

X 
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8.7.2-3 

During the warranty and SMA terms, the Program needs the SI to respond to reports of system outages within 30 
minutes of notification, 24 hours a day, seven (7) days a week. A fully-qualified service representative will be onsite as 
soon as possible, and no more than 24 hours after being contacted by Agency staff, if it is determined that a physical 
oresence is needed to resolve the identified issue. 

X 
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8.7.2-4 

During the warranty and SMA terms, the Program needs the SI to respond to a report of any software defect or 
malfunction within one hour of notification during Agency business hours. A fully-qualified service representative will be 
onsite as soon as possible, and no more than 24 hours after being contacted by Agency staff, if it is determined that a 
ohvsical oresence is needed to resolve the identified issue. 

X 
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Desired 

8.7.2-5 

Program needs the SI to maintain a change log of all changes that are performed, and provide this change log to the 
Agencies on a mutually agreed upon schedule. The change log must be sufficiently detailed to allow the Agencies to 
determine when any feature was added or modified, and the scope of the change. The change log will conform to the 
change management oolicies defined in the change management olan. 

X 
















































Capability 

Subsection 

Capability 

Type 

Capability 

Number 

Capability 

Fully Conforming 

Nonconforming 

Comments 
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8.7.2-6 

Advance notification will be provided, as defined by the change management policies outlined in the change 
management plan, for all software maintenance activities. 

X 



8.7.2-7 

The Program needs the SI to submit to the Agencies no less than every two weeks a bulletin setting forth planned 
modifications and updates to the software, upgrade schedules, and a calendar of key dates for system changes for the 
coming three months and beyond. The bulletin will conform to the change management policies defined in the change 
management olan. 

X 



8.7.2-8 

Throughout the SMA term, the Program needs the SI to document all equipment repairs, adjustments, or replacements 
within a maintenance management system, by the end of each day. 

X 



8.7.2-9 

If a software problem impacts revenue collection, but repair will take longer than three (3) hours, the Program needs the 
SI to report the cause of the problem as soon as it becomes evident, and provide status reports at least every four (4) 
hours thereafter, until the problem is corrected or a workaround is established. 

X 



Software Change Management 

Mandatory 

8.7.3-1 

Without releasing the SI from its obligations under the warranty and SMA, the Agencies have the right to refuse to install 
any updates, at their sole discretion. 

X 



8.7.3-2 

During the term where the SMA is in effect, the SI shall update training course materials and manuals as needed to 
reflect software changes performed under the agreement. 

X 



8.7.3-3 

All changes to any delivered and installed part of the System must comply with the mutually agreed upon change 
request and software deployment procedures defined in the Si's Project Management Plan. 

X 



Desired 

8.7.3-4 

The Program needs the SI to track and maintain a list of software maintenance issues and open items. The Program 
needs the SI to distribute the list to the Agencies in advance of each monthly meeting. 

X 



8.7.3-5 

Software and firmware updates will be clearly documented and submitted in advance of deployment for Agency review 
and approval. 

X 



8.7.3-6 

During the warranty and SMA terms the Program needs the SI to provide updated course instruction and materials 
resulting from any significant system hardware or software changes. 

X 



8.7.3-7 

The Program needs the SI to support software change management meetings no less than monthly throughout warranty 
and SMA terms, either in person or via phone. 

X 



8.7.3-8 

The Program needs the SI to keep all software environments (training, test, development, staging, and production) at the 
same configuration and patch level as appropriate. 

X 



8.7.3-9 

The Program needs the SI to notify the Agencies whenever corrections, modifications or revisions of system software are 
available. 

X 



8.7.3-10 

As standard practice when repairing deficiencies and releasing device or back office system fixes or upgrades, the 

Program needs the SI to prepare and run regression testing scripts to test that each build delivered to the test 
environment does not result in any issues with the devices and systems currently in operation, including those that are 
not being undated. Anv reeression issues will be documented as deficiencies and resolved accordinelv. 

X 
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Mandatory 

3 1 

The SI shall provide to the Agencies all support required to develop and deploy such enhancements at the Si’s labor rates 
specified in the price schedule. 

X 



Desired 

8.7.4-2 

The Program needs the SI to provide timely response to requests for software enhancements (customizations) by the 
Agencies that are not covered by the warranty or SMA. Enhancements include modifications to the software that add 
capabilities and improve or change software functions that are not modifiable using the System configuration 
oarameters defined in this SOW. 

X 



Section 8.8 Field Equipment Maintenance 


nent Maintenance 

Mandatory 

8.8-1 

A detailed service operations document including service procedures and VM screen flows will be provided during design 
review for Agency review and approval. 

X 




8.8-2 

Spare devices and modules used for all maintenance activities performed prior to Final System Acceptance will be 
replaced with functional equipment a maximum of 14 calendar days after use. 

X 



8.8-3 

The SI will provide instructions and pricing for the purchase of replacement devices and modules for all Sl-supplied 
equipment, including but not limited to: 

* Onboard validators 

* Wayside validators 

* Driver display units 

* CST (and all peripherals) 

The purchase of replacement equipment may be through the SI or OEM, and pricing may be provided for repaired or 

X 



8.8-4 

The Program needs the SI to provide a recommended list of spare modules and parts to support the installed fleet at 
completion of SAT. Recommended quantities will be provided based on expected usage. 

X 
















Capability Capability 

Subsection Type 


Capability 

Number 




8.8- 


The Program needs the SI to provide a recommended list of consumables at completion of SAT to support system 
operations for one year. Consumables are items that have a limited life cycle due to constant use and are expected to be 
replaced on a frequent basis, such as bulbs, fuses, and receipt paper. Recommended quantities will be provided based 
on expected usage. 

X 



8.8- 


The Program needs the SI to provide a list of special tools needed to maintain the System at completion of SAT. Special 
tools are defined as special diagnostic tools and equipment that is not readily available from commercial sources. The 
Program needs the SI to provide sufficient documentation to allow the Agencies to manufacture these tools. 

X 



8.8- 

7 

The Program needs the SI to not modify or repair any equipment in revenue service without the approval of the ROOT or 
an Agency-authorized representative. 

X 



8.8- 

8 

During the warranty, the Program needs the SI to ship replacement modules within one business day of receipt of any 
field equipment returned for repair/replacement. 

X 





Section 8.9 Agency Test Facility 


The Program needs the SI to update the Agency test facility for the duration of the contract. 


Section 8.10 Fraud Controls 


The SI shall be responsible for maintaining the System's fraud control capabilities for the duration of the contract. 


Section 8.11 Disaster Recovery 
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Mandatory 

8.11-1 

The SI shall maintain the Disaster Recovery Plan for the duration of the contract. The plan will conform to the required 
service level agreement and be consistent with the Business Continuity Plan and recovery time capabilities. 

X 
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8.11-2 

For Sl-hosted solutions, the SI must have a current Disaster Recovery Plan in place for both IT and non-IT related 
disasters for the duration of the contract. 

X 



Section 8.12 Performance Measurement 


The SI shall submit a Performance Maintenance Plan for review and Agency approval during design review identifying the 
approach to measuring and reporting on performance against KPIs. 


The SI shall be responsible for measuring performance against all KPIs. 


The SI shall automate the capture of all necessary data and KPI calculation wherever possible. For validation purposes, 
the Agencies will have full access to the source data and code used to perform the calculations. 


System performance will be measured using the data generated and stored by the System. Data generated manually will 
be used when it is the only option for tracking an activity associated with a particular KPI (e.g., response time). 



8.12.1-5 

The Program needs the SI to commence performance measurement during the SAT and continue to perform this activity 
throughout the operations agreements. 

X 

Mandatory 

8.12.3-1 

The FRB will be established prior to the start of acceptance testing to evaluate equipment and back office failures, as well 
as other system issues, throughout acceptance testing. 

X 

8.12.3-2 

The acceptance test plan submitted by the SI will include a proposed FRB structure and system performance review 

process. 

X 


8.12.3-3 

The Agencies' project manager will make the final and binding decision on any disputes that remain unsettled by the FRB 

after a period of 10 business days. 

X 

Desired 

8.12.3-4 

The members of the FRB will attempt to settle any disputes based on the requirements in this SOW, and will use best 
judgment in any scenarios where the requirements are silent or unclear. 

X 

8.12.3-5 

At a minimum, the Failure Review Board (FRB) will be comprised of the Agencies' project manager, or a designated 
representative, and the Si's lead engineer. 

X 

8.12.3-6 

The FRB will be responsible for the review and approval of the acceptance test plan, and shall agree to the criteria for the 
execution and approval of the acceptance test phases. 

X 

8.12.3-7 

During acceptance testing, the FRB shall meet no less than weekly. The FRB will review all failures and other system 
issues that arise during acceptance testing to assess their severity and impact on completion of this test phase. 

X 


8.12.3-8 

Following the prescribed SAT period, the FRB will make a recommendation on whether to approve or extend the test 
phase. Final discretion for the approval of acceptance testing and the granting of Final System Acceptance will reside 

with the Agencies. 

X 

8.12.3-9 

Following Final System Acceptance, the FRB will continue to meet monthly for the remainder of the operations 
agreements. During this time, the FRB will be responsible for reviewing system performance and settling any disputes 

around measurement of the KPIs. 

X 
























































Capability 

Subsection 

Capability 

Type 

Capability 

Number 

Capability 

Fully Conforming 

Nonconforming 

Comments 

Failure Review Board 

Desired 

8.12.3.1-1 

Non-chargeable failures include, but are not limited to, the following: 

• Mishandling of equipment or back office system components 

• Any failures caused by externally applied stress conditions outside of normal operating conditions and in excess of the 
requirements in this SOW 

• Failures caused by incorrectly exercised operating, maintenance or repair procedures performed by the Agencies where 
correct procedures have been delivered by the SI (failures resulting from any maintenance or repair performed by the SI 
will be chargeable) 

• Failure caused by vandalism 

• Communications failures beyond the control of the SI 

• Downtime due to scheduled maintenance 

• Heater or battery adjustments 

• Dependent failures as a result of a non-chargeable failure 

X 



8.12.3.1-2 

All other failures will be considered relevant and chargeable unless determined to be non-chargeable by the FRB. 

X 



8.12.3.1-3 

Non-chargeable failures will not affect the reliability, accuracy, and availability KPI calculations. 

X 



8.12.3.1-4 

Chargeable failures include, but are not limited to, the following: 

• A malfunction which prevents the System component from performing its designated function, or meeting the 
performance criteria, when used and operated under the environmental and operational conditions stated in this SOW 

• A malfunction that might cause a threat to customers, employees, or others 

• An occurrence that does not cause the System component to become entirely inoperable, but requires some form of 
maintenance attention to restore normal function 

• Any occurrence where data is not successfully transmitted between elements of the System 

• Planned software updates or fixes that adversely affect the operation or performance of the System 

• Scheduled maintenance or repair activities that adversely affect the operation or performance of the System 

X 



8.12.3.1-5 

The following specific conditions, at minimum, will be considered chargeable failures in any components or Systems 
delivered: 

• Software anomalies and bugs (every incident of a software anomaly or bug causing a malfunction will be considered a 
failure) 

• Hardware failures that are not clearly a result of conditions outside the requirements of this specification 

• Failures of mounting hardware 

• Data storage failures, including those due to the disk space provided 

• Partial or complete failure of a passenger display 

• Failure to accurately read and/or process a card 

• Failure to properly register and report any transactions 

• Data download/upload failure 

• Event or alarm transmission failure 

• Unexpected shutdown of equipment or the System 

• All maintenance requiring module replacements 

X 



8.12.3.1-6 

Under mutual agreement, the FRB will classify additional failures as chargeable or non-chargeable as required. 

X 



8.12.3.1-7 

Chargeable failures will affect the reliability, accuracy, and availability KPI calculations. 

X 




Mandatory 

8.12.4-1 

The SI shall be responsible for reporting on performance against all KPIs on a monthly basis. 

X 



8.12.4-2 

The SI shall commence performance reporting during SAT and continue to perform this activity throughout the 
operations agreements. 

X 




8.12.4-3 

The Program needs the SI to provide up to 100 hours of design for Agency-specific modification of provided canned 
reports. 

X 
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Subsection 

Capability 

Type 

Capability 

Number 

Capability 

Fully Conforming 

Nonconforming 

Comments 

Performance Reporting 

Desired 

8.12.4-4 

At a minimum, the following reports will be provided: 

• Device reliability 

• Device accuracy 

• Device availability 

• Back office accuracy 

• Back office availability 

• Server authorization rate 

• Maintenance response time 

X 



8.12.4-5 

The reports will be generated without manual data entry by the SI wherever possible. 

X 



8.12.4-6 

The reports will include tables and graphical charts showing the current and historical performance of each device of 
system under measurement. 

X 



8.12.4-7 

The reports will include a calculation of any credits to be assessed in the current month based on current and prior 
performance. 

X 



8.12.4-8 

The Program needs the SI to create canned reports that can be run, viewed, and downloaded by the Agencies using the 
reporting system. These reports will not count toward the custom reports to be defined by the Agencies. 

X 



Credit Assessment 

Desired 

8.12.5-1 

Credits will be granted for a failure to meet any KPIs identified as having an associated credit. 

X 



8.12.5-2 

Credits will be determined as a percentage of the operations payments made to the SI. The credit percentage and 
operations payment associated with each KPI will be determined during negotiations. 

X 



8.12.5-3 

The SI will have three opportunities to meet the KPI as measured. By the third assessment period (the third consecutive 
month) if the measurement is not meet, it will be deemed a failure and a credit granted. 

X 



8.12.5-4 

The credit multiplier will increase by a factor of one for each month that a KPI is not met, up to the full value of the 
associated operations payment (e.g., if a KPI is not met two months in a row, the credit will be doubled in the second 
month; if a KPI is not met three (3) months in a row, the credit will be tripled in the third month) 

X 



8.12.5-5 

Successfully meeting a KPI will end a persistent failure and reset the credit multiplier. 

X 



8.12.5-6 

The total credit applied to an operations payment will not exceed the full amount of the operations payment in that 
month. Credits will not be carried over from month to month. 

X 



8.12.5-7 

The Program needs the SI to be responsible for reporting on credits in the System performance reports and will deduct 
credits directly from any invoices submitted to the Agencies. 

X 












Capability 

Number 


Number 

Capability 

Section 3 System Design & Architecture 

Section 3.1 Common Design Capabilities 


Software and hardware provided under this contract will be designed to provide a minimum useful life of 12 years from 
commissioning date. 

3.1.1-2 

To establish a design as service-proven, the SI shall submit specific details of the design's application history, certified by 
current users of the equipment. 

3.1.1-3 

The SI may offer, for approval, a design which is largely unchanged from a service-proven design, but which varies 
slightly in design or manufacture to meet the capabilities of this SOW, including newer generations of service-proven 
equipment. The Program needs the SI to show, in detail, what has been changed and why such changes will not 
adversely affect operation or maintenance in the planned environment. 

■ 

The System design will be service-proven. As service-proven, or derived from a service-proven design, the System design 
will meet all of the following criteria: 

• Has been deployed and met system acceptance requirements at a minimum of one (1) transit agency with bus and rail 
operations 

• Has been deployed and successfully integrated frontend equipment with a back office system at a minimum of one (1) 
transit agency 

• Has been deployed and achieved a level of reliability, accuracy, and availability consistent with the performance 
requirements in this SOW at a minimum of one (1) transit agency 

3.1.1-5 

Proposed vending machines will be nearly identical in design and construction to a model deployed and in revenue 
service (i.e., in use and passed system acceptance) at a minimum of one (1) transit agency. 

3.1.1-6 

Proposed wayside and onboard validators and associated onboard equipment will be nearly identical in design and 
construction to a model deployed and in revenue service (i.e., in use and passed system acceptance) at a minimum of 
one (1) transit agency. 

3.1.2-1 

At the time of delivery, equipment, and all associated components and software will contain no prototype, obsolete, or 
discontinued products. Any hardware or software components that have an end-of-life prior to expiration of warranty 
must include replacement plans to be executed at the Si's cost. 

3.1.2-2 

The System will be designed using open standards for software design, communications protocols, fare media, and other 
relevant design components. 

3.1.2-3 

Software applications and devices will be built using Commercial off the Shelf Software (COTS) components where 
possible, and custom software and hardware modules only if necessary and approved by the Agencies. 

u 

Fare media will be available for competitive purchase from multiple U.S. sources. The Program needs the SI to provide 
the specifications and associated documentation necessary to support the future procurement of fare media from third 
parties. 

3.1.2-5 

The System will have a modular design for all relevant components. These modules will support field replacement to 
return a device to service in minimal time, as determined and approved during system design and testing, in the event of 
a failure. The System will also permit upgrades and configuration changes without requiring component replacement or 
redesign. 

3.1.2-6 

In order to reduce the cost and complexity of device maintenance, all devices, components, parts, modules, assemblies, 
and subassemblies provided will be fully interchangeable among those of the same type without the need to make 
adjustment for proper compatibility. 

3.1.2-7 

The System will be designed so that technology upgrades may be done with no or minimal redesign of components, 
modules, and software, or other work. 

3.1.3-1 

The Program needs the SI to furnish equipment and materials from the manufacturers identified in the Si's deliverables, 
unless otherwise approved. 
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Capability 


The Program needs the SI to select and supply devices, components, parts, modules, assemblies, and subassemblies, as 
well as software and other essential elements of the System, based on projected availability and long-term original 
equipment manufacturer (OEM) support commensurate with the required useful life of the System. 


If any vital device, component, part, module, assembly, or subassembly, or support for OEM software, is being 
discontinued or obsoleted by the SI or OEM, the Program needs the SI to notify the Agencies a minimum of six (6) 
months prior to last available date of purchase or support. 


The Program needs the SI to work with the Agencies to find or develop a suitable replacement for any device, 
component, part, module, assembly, subassembly, or software that is obsoleted by the SI or OEM. If the SI chooses to 
obsolete any Sl-provided equipment or software within 12 years from Final System Acceptance, all hardware and 
software development costs necessarv to support a replacement will be borne bv the SI. 


All components of the System will be constructed of the highest quality materials suitable for production-level use in the 
intended environment over the required useful life of the System. The SI shall use only new components conforming to 
the capabilities of this SOW and approved by the Agencies. This does not preclude use of recycled materials in the 
manufacture of new components. 


The SI shall be responsible for all materials and workmanship. It is the Systems Integrator's responsibility to design, 
select, and apply all materials necessary to meet the capabilities of this SOW. If alternate materials are offered following 
selection, it is the responsibility of the SI to demonstrate that the alternate materials are equivalent to the proposed 
materials, and to obtain Agency approval for the substitution prior to any implementation. 


All SI provided equipment will be free from safety hazards and will be designed to comply with relevant Underwriter's 
Laboratory (UL) Standards. All interior and exterior surfaces will be free from sharp edges, protrusions, exposed wires, or 
other hazards. 


If it is found that approved sources do not furnish a uniform product, or if the product from such source proves 


The SI shall supply all necessary software applications and shall design and configure all device and back office software 


System software will incorporate the following design elements at a minimum: 


System software will incorporate the following controls at a minimum: 


System software will incorporate the following diagnostic capabilities at a minimum: 


Software upgrades will be centrally managed and fully tested prior to installation. The System shall be able to roll-back 


All third-party software will be at the latest commercial release at the time of FDR. If a release candidate is pending, the 


The System interfaces will be user-friendly and provide easily-configurable dashboards and graphics as determined 
during design review. 


The SI will work closely with the Agencies' IT and web services teams to develop an approved user interface design. The 
Agencies will play a critical role in the website design and testing throughout the implementation._ 


System equipment will provide customers and Agency users with displays, graphics and signage, controls and 
mechanisms that are simple to use, easy to understand, and conveniently located as determined during system design 
and testing. By following instructions given on and by the equipment, an inexperienced user will be able to understand 
all transaction processes and results. All such user interfaces will be user-friendly; that is, safe, predictable, simple to use, 
accessible for persons with disabilities, and in accordance with other applicable human engineering principles. 


The System equipment will provide reliable operation over its useful life, and will be designed to require minimal 
scheduled and unscheduled maintenance. 



MOBILEsymon, our system monitoring application already has several dashboards that can be used. 
In other applications (e.g. Revenue Management) we think that a tabular representation of data 
makes more sense. This is why we think that we are partially compliant to the 'provide easily- 
configurable dashboards' part of this requirement. 
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Number 

Capability 

3.1.7-2 

Automatic diagnostic test routines (and equipment if necessary) will be included to aid in troubleshooting malfunctions. 
These test routines will provide the capability to isolate defects down to the Lowest Level Replaceable Unit (LLRU). 

3.1.7-3 

The SI shall provide documentation and a Maintenance Plan during PDR that defines at a minimum: 

• Preventative Maintenance frequency for all system devices based upon time and transactions 

• A list of all Preventative Maintenance tasks to be performed, including a brief description of the work, and any parts, 
materials, or other components required 

• Time required to complete each defined Preventative Maintenance task 

• Which Preventative Maintenance tasks require tools to complete, and which can be performed as "fingertip 
maintenance" 

m 

The interior of the System equipment will be designed to allow easy and safe access. Adequate space will be available to 
insert keys; grasp, lift, and turn internal components; and remove and replace components, connections, and 
consumables. As appropriate, guides, rails, tracks, handles, and captive fasteners will be provided to facilitate module 
installation and removal. 


Any component or module that must be lifted (except for cash containers when full) will not weigh more than 20 
pounds. Any exceptions to this weight limitation will be subject to Agency approval. 


For ease of service and replacement, all electrical connections between components and subassemblies will be 
established by means of connectors that allow rapid removal of a component or subassembly. Plug-in connectors will be 
equipped with strain relief to prevent damage to cables and connectors. 


Components requiring frequent adjustment or maintenance will be conveniently located as determined during design 
and testing, and designed to facilitate access and adjustment utilizing tool-free techniques wherever possible. 


All devices will have clear labels and symbols that at a minimum indicate safety warnings, servicing steps, and wiring 
connections. 


No more than one person will be required to perform corrective maintenance, with the exception of vandalism, on an 
individual piece of equipment. 

3.1.7-10 

The System will have a modular design for all relevant components. These modules will support field replacement to 
return a device to service in minimal time in the event of a failure. The System will also permit upgrades and 
configuration changes without requiring component replacement or redesign. 

3.1.7-11 

The replacement of field devices or components will be quick and secure as determined during design review. 

3.1.8-1 

The System will be sized such that the total number of possible transactions, and total concurrent use of transit 
accounts, will at a minimum support 200% of the projected regional ridership totals and peak usages supplied by the 
region. 

3.1.8-2 

Scaling the System will in no way impact the overall performance of the System, the KPIs to which the System must 
meet, and any of the requirements contained in the SOW. 

3.1.9.1-1 

All system components and mounts will be sufficiently constructed to comply with local codes regarding stability of 
structures and contents in earthquakes, high velocity wind (up to 60 miles per hour), and other natural phenomena. 

3.1.9.1-2 

All system components will be designed to withstand structure-borne stresses and vibrations caused by the motion of 
transit vehicles, daily customer use, passing of trains or other vehicles, and emergency braking of fully-loaded trains. 


3.1.9.1-3 


All system components, including all interior-mounted components and assemblies, will resist horizontal shocks of up to 
6 g (where "g" is the acceleration of gravity at sea level, or 9.81 meters per second squared) and up to 1.2 g in the 
vertical axis for a duration of uo to 12 milliseconds (ms) without permanent deformation or failure. 


Fully Conforming 
NonEonforming 



X 
























































Capability 

Number 







Capability 


There will be no failure of mounts or decrease in operational performance of any system components under conditions 
simulated by a sinusoidal sweep vibration test at a sweep rate of one-half octave per minute, from 5 Hz to 200 Hz to 5 
Hz, at a peak vibratory acceleration of 0.25 g for a minimum of 50 cycles when applied to each of the three axes and 
repeated continuously for five (5) complete cycles. If any assembly or component is a source of vibration, measures will 
be taken to dampen the vibration. Resonant frequencies that may exist in the mounted structures will be critically 
dampened. All corrective measures must be approved bv the Agencies._ 


Onboard equipment, including onboard validators and driver display units, will pass the following shock and vibration 
tests: 

• I EC 60068-2-27 

• I EC 60068-2-64 


Rail equipment, including vending machines and wayside validators, will pass the shock and vibration tests specified in 
the ERTMS/ETCS Environmental Requirements (e.g., EEIG 97s0655). 


Onboard equipment, including onboard validators and driver display units will be protected to prevent degradation in 
performance from exposure to moisture or dust raised by inclement weather or interior cleaning. Operation of the fare 
collection equipment in this environment will not in any way impair equipment performance throughout the required 
useful life of the System. 


Onboard equipment, including onboard validators and driver display units, will be designed, built, and installed for the 
harsh, high shock and vibration operating environment in which the System components will be installed. Operation of 
the fare collection equipment in this environment will not in any way impair equipment performance throughout the 
required useful life of the System. 


The onboard equipment provided by the SI will be able to operate and not suffer any degradation in performance under 
the following environmental conditions: 

• Storage temperature: -22° to +150°F 

• Operating temperature: -15°F to 140°F ambient 

• Thermal shock: Up to 50 degrees F in 1 hour, non-condensing 

• Relative humidity: 5-100%, non-condensing 

• Airborne dust: up to 180 micrograms per cubic meter, with iron and salt particles 

• Sunlight: direct sunlight, radiation loading of up to 789J/sec/m2 

• Inclination: 0° to 20° off vertical 

• Rainfall: 10 inches over 12 hours 

• Water/solvents: IEC529 to level IP54 or equivalent 

• Pollution: Vog (e.g. sulfur dioxide-laden air) and other forms of native air pollution 

• Other operational conditions: water spray, industrial cleaning solvents, and mud on system components from cleaning 
vehicle floors and walls 


The onboard equipment will be either immune to or protected from the damaging effects of visible spectrum and 
ultraviolet radiation. 


The onboard equipment will be designed to be resistant to liquid ingress caused by driving rain, or by splashed water or 
cleaning chemicals, such as would occur during routine equipment and vehicle cleaning. 


Means will be provided to detect failure of any cooling device and provide for a controlled shutdown of the System 
components and generation of a maintenance event. 


The onboard equipment will be tested and certified to operate under the environmental conditions specified in Society 
of Automotive Engineers (SAE) J1455 and all standards contained therein._ 




INIT products are vibration tested according European Railway standards EN50155. In EN50155 
sinusoidal testing has been replaced with broad band random vibration. Test parameters used by INIT 
are: Frequency range of 5-1000Hz, Acceleration 1.3g rms, sweep time 5h per axis. The standard 
intends to simulate 25 years of usage onboard a rail vehicle. 


































Capability 

Number 

Capability 

Fully Conforming 

NonBonforming 

Comments 

3.1.9.3-1 

The wayside equipment provided by the SI will tolerate the environment in which it is installed and stored. The 
equipment will be able to operate and not suffer any degradation in performance under the following environmental 
conditions: 

• Storage temperature: 0° to +140°F 

• Operating temperature: -15°F to 140°F ambient 

• Thermal shock: Up to 30°F in 1 hour, non-condensing 

• Relative humidity: 5-100%, non-condensing 

• Airborne dust: up to 180 micrograms per cubic meter, with iron and salt particles 

• Sunlight: direct sunlight, radiation loading of up to 3MJ/hr/m2 

• Platform Inclination: 0° to 10° off vertical 

• Rainfall: 10 inches over 12 hours 

• Water/solvents: IEC529 to level IP65 or equivalent 

• Pollution: VOG and other forms of native air pollution 

• Other operational conditions: water spray, industrial cleaning solvents, and mud on system components from cleaning 
station floors and walls 


X 

The validator is IP54 classified, but the suitability for outdoor use is already proven in Portland. We 
propose to not redesign the validator for IP65 to avoid development risk that could impact the 
project timeline 

The VM is IP54 with the exception of the credit card reader and the coin / bill acceptor that is IP34. 
There is no credit card reader with IP 54 (since you have to be able to enter a credit card). This is 
industry standard. 

3.1.9.3-2 

VMs will be subject to incidental moisture from customers and cleaning through coin, bill, and ticket slots, and other 
openings and enclosure joints, and will be designed for proper operation under such conditions. All exposed surfaces, 
including push buttons, the display screen, and coin and bill components will be unaffected by detergents and cleaning 
solvents. Means will be provided to expel moisture from the VMs to support continued, reliable operation. 

X 



3.1.9.3-3 

Means will be provided to detect failure of any cooling device and provide for a controlled shutdown of the System 
components and generation of a maintenance event. 

X 



3.1.9.3-4 

The wayside equipment will be either immune to or protected from the damaging effects of visible spectrum and 
ultraviolet radiation. Internal components that may be either damaged or affected operationally when exposed to direct 
sunlight will be protected from exposure during maintenance activities without requiring specific action by maintenance 
personnel. 

X 



3.1.9.3-5 

The wayside equipment will be designed to be resistant to liquid ingress caused by rain, or by splashed water or cleaning 
chemicals, such as would occur during routine equipment and platform cleaning. 

X 



3.1.9.3-6 

Wayside equipment, including wayside validators and VMs will be protected to prevent degradation in performance 
from exposure to moisture or dust raised by inclement weather or cleaning. Operation of the fare collection equipment 
in this environment will not in any way impair equipment performance throughout the required useful life of the 

Svstem. 

X 



3.1.9.4-1 

CSTs will be designed and configurable to be installed in Agency facilities. Operation of the equipment in this 
environment will not in any way impair equipment performance throughout the required useful life of the System. 

X 



3.1.9.4-2 

Means will be provided to detect failure of any cooling device and provide for a controlled shutdown of the System 
components and generation of a maintenance event. 

X 



3.1.10.1-1 

The SI shall design, supply, install, test, and commission all internal system components necessary to provide the 
required electrical power to the Sl-supplied equipment. 

X 



3.1.10.1-2 

Electrical power will be obtained from existing power sources and will be filtered, transformed, converted, battery- 
stored, and distributed by the SI as required, including all necessary connections and terminations. 

X 



3.1.10.1-3 

Onboard equipment, including onboard validators and driver display units, will be designed to operate reliably from a 
vehicle's direct current power source, which will be either 12 volts or 24 volts of direct current (VDC). 

X 



3.1.10.1-4 

Primary power will be provided by the Agencies at equipment installation locations, and may not be clean or isolated at 
the voltage levels required by the Sl-supplied equipment. Any necessary conditioning of the primary power, or addition 
of line interface filters or power supplies, will be the responsibility of the SI, and to the greatest extent possible, will be 
performed within the equipment enclosures. 

X 





















Capability 

Number 

Capability 

3.1.10.1-5 

All system components operating off of line voltage will be designed to operate with a plus or minus 10% fluctuation in 
voltage without any damage or interruption. 

3.1.10.1-6 

In the event of a loss of electrical power, field equipment will complete any transaction in process, retain all data, and 
shutdown in an orderly manner. The equipment will return to full operational status after a power failure without 
manual intervention or adversely affecting the integrity of stored data. 

3.1.10.1-7 

All equipment will be protected against damage or data loss under the following conditions: 

• Voltage fluctuations 

• Reverse polarity of the input voltage 

• Temporary voltage variations (0 to 50 V) 

• Over-current draw 

• Stray currents 

3.1.10.1-8 

The onboard equipment power supply will include adequate filters and components to regulate the bus-supplied voltage 
and render it devoid of power spikes and noise. Provisions will include elimination of power fluctuations caused by 
fluorescent lights, coach alternators, coach startup (cranking), air conditioning units, radio communication units, and 
other svstems characteristic of a bus environment. 

3.1.10.1-9 

Adequate protection against onboard transient power surges, as determined during system design and testing, will be 
incorporated to the extent necessary to prevent damage to the electronic components of the onboard equipment. 

3.1.10.1-10 

Power sensing will be incorporated into onboard equipment power supplies to cause the devices to switch off 
automatically if the supply voltage increases or decreases to levels beyond the voltage tolerance. 

3.1.10.1-11 

All system components will retain any information stored in non-volatile memory under any conditions of the supplied 

power. 

3.1.10.2-1 

The SI shall certify the electromagnetic compatibility of system components to be furnished. The SI shall provide the 
results of interaction analysis and testing of each system component with regard to frequency distribution, amplitude, 
and harmonic content for review and approval during design review. 

3.1.10.2-2 

The Program needs the SI to confirm system equipment will operate without being adversely affected by or causing 
electromagnetic interference (EMI). 

3.1.10.2-3 

All system components will include protection against external EMI and radio frequency interference (RFI) emissions, as 
well as internal conductive or inductive emissions. 

3.1.10.2-4 

All system components will conform to the following capabilities: 

• FCC Part 15, Subpart B Class A (Conducted emissions), pertaining to conducted susceptibility 

• FCC Part 15, Subpart B Class A (Radiated emissions), pertaining to radiated susceptibility 

3.1.10.2-5 

Equipment will not emit measureable EMI or RFI that produces harmful interference with any other onboard or station 
devices or systems, including Global Positioning System (GPS) and magnetic compass readings, and will comply with the 
following standards: 

• IEC 1000-4-6 (EN61000-4-6) pertaining to conducted susceptibility 

• IEC 6100-4-3 (EN61000-4-3) pertaining to radiated susceptibility 

• IEC 6100-4-2 (EN 6100-4-2) pertaining to electrostatic discharge 

3.1.10.2-6 

Operation of the equipment will not be affected by the electromagnetic fields generated by traction power (overhead 
catenary or third rail) or by local high voltage power distribution lines. 

3.1.10.2-7 

Operation of the wayside equipment, including VMs and wayside validators, will not be adversely affected by the 
operation of other station equipment, such as lighting and communications equipment, within close proximity. 

3.1.10.2-8 

Onboard equipment, including onboard validators, and driver display units will be unaffected by interference from 
fluorescent lights, coach alternators, air conditioning units, radio communication units, and other systems characteristic 
of a bus environment. 
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Number 

Capability 

3.1.10.2-9 

Equipment communications will not interfere or be impacted by the use of established frequencies, including but not 
limited to: 

• Audio frequencies for overlay track circuits, highway crossing approach and island circuits, and electrical lock circuits 

• Audio frequency code overlay for Automatic Train Control (ATC) systems 

• Signal power 

• Cab signals 

3.1.10.3-1 

All equipment enclosures, chassis, assemblies, panels, switch boxes, and terminal boxes will be grounded. Protective 
grounding will be provided to make sure that exposed metal on all system components is connected to a common 
ground point. 

3.1.10.3-2 

The Program needs the SI to meet safety capabilities for the grounding that conforms to the National Electric Code (NEC) 
and UL, SAE and local codes where applicable. 

3.1.10.3-3 

The Program needs the SI to provide certification that all system components furnished have been tested to meet 
applicable UL criteria. Documentation citing UL certification or acceptable test results will be provided for review and 
approval during design review. 

3.1.10.3-4 

System equipment will be equipped with Ground Fault Circuit Interrupter (GFCI) circuit breakers, which include a "push 
to test" button, visible indication of a tripped condition, and ability to detect an earth leakage current of approximately 5 
milliamperes in accordance with UL 1053 and California Energy Commission (CEC) standards. 

3.1.11-1 

The Agencies will own all data generated by the equipment, systems, and software delivered under this Contract. The 
Agencies will be able to freely access and distribute all data free of charge. The Agencies will retain ownership of all data 
in perpetuity with no restrictions or additional cost. 

3.1.11-2 

All documentation described in this SOW will become the property of the Agencies, or provided under a perpetual 
license to enable internal use, editing, and distribution to third-parties at no additional cost. 

3.1.11-3 

Any reports generated by the System are the sole property of the Agencies and will not be shared or distributed without 
Agency express written permission. 

3.1.11-4 

The Program needs the SI to develop a Software Licensing and Documentation Plan for Agency approval. The Plan will 
identify all system software and interfaces and any applicable terms that apply to the use and distribution of the covered 
components. 

3.1.11-5 

All system and software interfaces will be defined and documented, and will be provided to the Agencies under a 
perpetual license to enable internal use and distribution to third-parties at no additional cost. 

3.1.11-6 

All open architecture API, libraries, and Intellectual Property (IP), including data exchange formats and algorithms, will be 
provided to the Agencies under a perpetual license to enable internal use and distribution to third-parties at no 
additional cost. 

3.1.12-1 

All equipment, software, employee and customer interfaces will meet or exceed ADA standards to maximize ease of use. 
The System equipment will comply with the most recent version of the ADA Accessibility Guidelines (ADAAG) at the time 
of Final System Acceptance. 

3.1.12-2 

All devices and systems will meet or exceed ADA and accessibility standards, which will include compliance with all 
current industry and government standards governing accessibility. The SI shall be fully responsible for tracking all 
required certifications, for the interfaces to the payment devices and the System as a whole, including any required 
certifications. 

3.1.12-3 

Accessibility guidelines and regulations will be incorporated in the design of the entire system from the onset. Usability 
will be tested in the design process and implementation. 

3.1.12-4 

All system and user interfaces will comply with section 508 of the Rehabilitation Act of 1973, which includes the Web 
Content Accessibility Guidelines (WCAG) 2.0, meet or exceed the WA State Accessibility Policy - Standard 188.1 
(https://ocio.wa.gov/policy/accessibility) and meet or exceed all ADA requirements. 


Comments 
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3.1.12-5 

The customer website and mobile app will be designed to be user friendly and accessible to current and potential riders 
and Agency employees. The System will comply with the most recent version of the ADAAG at the time of Final System 
Acceptance and will meet or exceed the WA State Accessibility Policy - Standard 188.1. 

3.1.12-6 

The SI will provide an Accessibility Compliance Plan during design review that articulates how the required ADA and 
accessibility standards will be met for the entire system during each phase of the project. This plan will be subject to 
approval by the Agencies. 

3.1.12-7 

The SI will provide an Accessibility Compliance Plan that articulates how the required ADA and accessibility standards will 
be maintained following implementation. This plan will include ongoing operations, change management, and a plan for 
updates when regulations change. This plan will be subject to approval by the Agencies. 

3.1.12-8 

The SI shall create an ADA compliance framework as part of the Accessibility Compliance Plan that will track compliance 
with all appropriate local, state and federal accessibility standards. 

3.1.12-9 

All equipment provided or purchased by the SI that will provide fare media or fare validation will be certified by the 
Original Equipment Manufacturer (OEM) or SI, as compliant with all applicable accessibility standards at the time of Final 
System Acceptance. 

3.1.12-10 

VM instruction text will include raised lettering and braille instructions that will meet or exceed all applicable 
accessibility and ADA requirements. 

3.1.12-11 

The VM display screen will display characters and symbols compliant with all accessibility and ADA requirements. 

3.1.12-12 

The onboard and wayside validator design and mounting will be in compliance with or exceed all applicable ADA 
requirements and will be approved by Agencies. 

3.1.12-13 

The onboard and wayside validator will have ADA-compliant visual and audible indicators that provide distinctive 
messages for approval or denial of all fare media validations and validator status. All validator visual and audio output 
will be fully configurable and subject to Agency review and approval during design review. 

3.1.12-14 

All customer-facing payment processing hardware and software will meet or exceed all applicable accessibility and ADA 
requirements. The design will be reviewed and approved during design review. 

3.1.12-15 

The SI shall be responsible for conducting all testing required to meet or exceed the current Accessibility and ADA 
regulations prior to Final System Acceptance. 

3.1.12-16 

All mobile app screens will use colors to enhance legibility and be in compliance with or exceed all applicable ADA 
requirements. 

3.1.12-17 

All mobile apps will utilize and be fully compatible with the native accessibility features of the mobile operating system. 

3.1.13-1 

All equipment that reads fare media for the purpose of fare distribution or validation will include a contactless validator 
that supports all common ISO-14443 (Type A and B), ISO-18092 (NFC), and closed-loop (e.g., the entire MIFARE product 
line) media formats, in addition to all open payment contactless standards, including but not limited to: 

• Apple Pay 

• Android Pay 

• Samsung Pay 

• VISA payWave® 

• MasterCard PayPass® 

• American Express ExpressPay® 

• Discover Zip® 

• Contactless EMV 


3.1.14.1-1 


The System will be designed to include the appropriate elements and processes to manage, monitor, and quickly address 
security issues, consistent with the expectations outlined in above, to support the operation of the region's Information 
Security Management System (ISMS). 
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3.1.14.1-2 

All devices and elements accepting bank cards for payment will be designed to facilitate compliance with (and potentially 
certification) all applicable industry and government standards and best practices governing payment processing 
systems. This will include, but not be limited to PCI-DSS and EMV. The SI shall be fully responsible for acquiring all 
required certifications, including PCI and EMV certifications, for the interfaces to the payment processor and the System 
as a whole. The region's ISMS requires that all standards of mandatory compliance are observed and all respective 
controls implemented to minimize the System's risk profile, and the potential impact to the Agencies. 

3.1.14.1-3 

The connection between the frontend devices and back office will be over a routable IP network. Where required, the 
connections will be secured using Transport Layer Security (TLS) and strong encryption, such as TDEA or AES. All data 
sent via the internet will be TLS-encrypted using the HTTPS protocol. Any IP communications must not preclude 
components of the Svstem utilizing IPv6. 

3.1.14.1-4 

Security-sensitive information will be submitted separately, outside of the normal document deliverables process, and in 
accordance with procedures to be jointly developed between the SI and the Agencies. Security-sensitive information will 
include: 

• Information that would allow an individual to create, duplicate, skim or counterfeit fare media 

• Information that would allow an individual to overcome security features or interlocks intended to prevent access to 
sensitive information 

• Information that would allow an individual to divert revenue, whether electronic or cash, from the System 

3.1.14.1-5 

System security features will be maintained and security issues will be addressed as they arise throughout the terms of 
the warranty and SMA. Operating system updates, software patches, bug fixes, and system enhancements to address 
identified security issues will be provided. 

3.1.14.1-6 

All fare payment data will be secured and private from the point when it is captured to when it is received by the 
processor. When communications are over public networks, approved secure methods will be used. 

3.1.14.1-7 

A regional ISMS will be deployed to manage security and monitor the status and version of all security standards 
applicable to the next gen ORCA System. The Program needs the SI to ensure that the necessary information to establish 
compliance with the controls identified by the ISMS is provided to facilitate its operation. The Program needs the SI to 
also ensure that all applicable standards, regulations, and best practices identified by it are accounted for in the region's 
ISMS. 

3.1.14.1-8 

The Program needs the SI to provide cryptographic key management services and tools. Key management in this context 
includes but is not limited to: 

• Key generation: Derived key generation for each manufactured fare media, including card manager key sets, as well as 
multiple application-related key sets (may include both encryption and authentication keys) 

• Key storage: Secure storage and retention of card and application key sets 

• Key updates: Capability to update, or roll, all cryptographic keys used within system 

• Key sharing: Secure sharing of application key sets with third-parties for use in multi-application environments 

3.1.14.2-1 

System must provide for configurable, role-based user access, so that users will only be able to access data and 
functionality pertaining to their respective job functions. 

3.1.14.2-2 

There will be a single common login across all SI built components of the System (users will not need a separate login to 
perform administrative functions). 

3.1.14.2-3 

The System will have the capability to establish an unlimited number of security roles. 

3.1.14.2-4 

The System administrator will have the ability to see all activity by user including at least last log in, reports opened, and 
other non-data submission activities. 

3.1.14.2-5 

The System will have the ability to set up access types (e.g., edit & read only) on an individual, role or group basis. 

3.1.14.2-6 

Some access types will have access to maintain and update customer accounts. 

3.1.14.2-7 

The Agencies will have read-only access to transactional databases with no data usage or ownership restrictions. 
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3.1.14.2-8 

Access to the back office applications will be controlled through the individual applications where Commercial off the 
Shelf (COTS) applications are concerned. For custom built application access will be controlled through the System using 
passwords and strict access privileges. 

3.1.14.2-9 

The System will manage and monitor all user accounts and access privileges. The System will have records of access 
rights to COTS software applications but not control. The System will control access to all custom applications. 

3.1.14.2-10 

Logical access to all supplied systems will require multi-factor authentication and be centrally managed using an Agency- 
provided, managed user authentication and access control platform based on an approved vendor-neutral, industry 
standard protocol, such as Lightweight Directory Access Protocol (LDAP) or equivalent. 

3.1.14.2-11 

Physical and logical access to components that contain Personally Identifiable Information (Pll) and/or financial data will 
be restricted. Physical and logical security will be sufficient for compliance with the PCI standards in effect at the time of 
Final System Acceptance. 

3.1.14.2-12 

The System will allow new security roles to be immediately reassigned upon role change of employees. 

3.1.14.3-1 

The SI shall use approved security in generating, storing, deploying, and transmitting cryptographic keys. The SI shall 
submit a cryptographic key management plan for agency review and approval during design review. 

3.1.14.3-2 

Solution must provide adequate controls for user access and encryption for sensitive information stored in and exported 
to and from the System. 

3.1.14.3-3 

The fare media format will support strong cryptography standards, such as Transparent Data Encryption (TDEA), 

Advanced Encryption Standard (AES) and RSA encryption to protect access to and modification of all data encoded to the 
media. 

3.1.14.3-4 

All data in the CRM will be encrypted using strong cryptography. Ciphers in use must meet or exceed the set defined for 
use in the United States National Institute of Standards and Technology (NIST) publication FIPS 140 2, or any superseding 
documents according to the date of implementation. The use of the AES is strongly recommended for symmetric 
encryption. 

Algorithms in use must meet the standards defined for use in NIST publication FIPS 140-2 or any superseding document, 
according to date of implementation. The use of the RSA and Elliptic Curve Cryptography (ECC) algorithms is strongly 
recommended for asymmetric encryption. 

Encryption ciphers and algorithms to be used will be approved by the ORCA Chief Information Security Officer. 
Additionally, all payment data must be stored in a tokenized form, whenever storage is required to support the 
functionality of the System. 

3.1.14.3-5 

If the System design requires the card manufacturer to encode the cryptographic keys to the fare media, the 
cryptographic key management plan will identify trusted card manufacturers with appropriate security mechanisms in 
place to certify that the cryptographic keys remain safe and secure. 

3.1.14.3-6 

The Program needs the SI to provide detailed specifications for the generation and management of all cryptographic keys 
used within the System. The key generation algorithms will be fully owned by or licensed to the Agencies, including the 
right to distribute specifications to third-parties for media production and to support multi-application smart card 
implementations without further approval, license, or payment. 

3.1.14.4-1 

The System and its applications must be in compliance with all applicable regulatory standards such as PCI-DSS, and 
recognized best industry practices for the protection of Pll at the time of deployment. 

3.1.14.4-2 

All equipment provided or purchased by the SI that will capture, store, transmit, or process bank card data will be 
certified, by the OEM or SI, as compliant with all applicable provisions of the PCI DSS standard at the start of revenue 
service. 


Comments 
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3.1.14.4-3 

The Program needs the SI to be responsible for providing a PCI compliance plan during design review, and for obtaining 
certification for the entire system. The Program needs the SI to employ a certified Qualified Security Assessor (QSA), and 
be responsible for conducting all testing required to achieve certification prior to Final System Acceptance. 

3.1.14.4-4 

The approach to system security will include avoiding the storage of bank card data and Pll on field devices whenever 
possible, and only storing and transmitting such data in a tokenized or encrypted form. 

3.1.14.4-5 

The Program needs the SI to be responsible for providing that the System as delivered is compliant with all applicable PCI 
standards at the time of Final System Acceptance, and with all Agency, state, and local policies for the handling of Pll. 

3.1.15-1 

The System will support fraud prevention policies, including the ability to automatically identify suspect usage patterns 
based on sales and ridership data, and block the use of fare media, transit accounts, and fare products based on 
configurable fraud rules. 

3.1.15-2 

The System will support Agency-configurable velocity checks, and other fraud prevention measures, that identify 
excessive or potentially fraudulent use of stolen or compromised fare media. 

3.1.15-3 

The System will support the setting of a configurable upper limit of rides for unlimited ride products (e.g., 50 rides for a 
one-day pass) that will generate an automated alert within the System, and optionally block the fare media or product, 
when the limit is reached. 

3.1.15-4 

The System will detect, and generate an automated alert for potential fraudulent duplication of fare media, if the same 
fare media or transit account is used for payment in two geographically separated locations within a configurable period 
of time. 

3.1.15-5 

For transit accounts with stored value, the System will support the configuration of a "floor limit," or value below which 
the balance is not allowed to fall (so long as the device generating a fare payment is online). The floor limit may be 
configured to be a zero or negative balance. Transit accounts with balances at or below the floor limit will be able to be 
automatically blocked by the System. 

3.1.15-6 

The System will support configurable rules to prevent the sharing of fare media and accidental payments through 
"passback protection," or a configurable time period in which fare media will not be accepted for payment at a device 
after an initial tap. Passback protection will be configurable by fare media type, fare product. Agency, mode, and 
passenger tvoe, and will be enforceable at the bus, rail station, and individual device level. 

3.1.15-7 

The System will support the placing of credentials and transit accounts into "observation mode", which will generate an 
automated alert when the credential or transit account is used. This may be used by fare enforcement staff to monitor 
known stolen or compromised credentials or transit accounts. 

3.1.15-8 

The blocking of credentials, transit accounts, and individual fare products will be able to be performed automatically and 
manually, and on an individual and bulk basis (i.e., if a known batch of cards was lost, the entire batch may be blocked). 

3.1.15-9 

Additional fraud prevention policies may be defined during design review. 

Section 3.2 System Architecture 

3.2.1-1 

The SI shall design, develop, and implement an account-based electronic fare collection system. The account-based back 
office will be the system of record for fare calculations and enforcement and take priority over any media that may hold 
account information. 

3.2.1-2 

An account-based back office supporting the System will manage transit accounts that store fare value loaded by 
customers, and enable use of that value for the payment of transit fares and transit-related services. 

3.2.1-3 

The account-based back office will process all transactions generated by the System devices, including loading transit 
accounts upon request from fare distribution devices, and performing fare calculation and balance updates at the time 
of fare payment based on established business rules. All fare processing and updating of transit accounts will be 
performed in real-time. 

















































Capability 

Number 


Capability 



The fare media including but not limited to smart cards and NFC enabled smartphones will serve as a credential for 
accessing transit accounts, and data will only be written to the media when loading or using fare value to support risk 
mitigation techniques. 

3.2.1-5 

The Account-based Transaction Processor (ATP) will have a module to configure and maintain apportionment rules 
based on fare products purchased and used, number and value of trips taken, and Agency associations. 

3.2.1-6 

The ATP apportionment module will have a user friendly interface to allow the rules to be securely maintained and 
updated, including the ability to change current rules and add new rules based upon new fare products, trip types, or 
Agencies being added to the next gen ORCA program. 

3.2.2-1 

Each fare validation and distribution device will be equipped to support real-time communications with the back office. 

3.2.2-2 

The communication interfaces will support real-time loading of fare value through all distribution channels. 

3.2.2-3 

All network connections will be supported by a high speed communication network provided by the Agencies. The 
Program needs the SI to provide a system that will function within each Agency provided network. 

3.2.2-4 

The communication interfaces will support real-time processing of closed-loop fare payments onboard vehicles. 

3.2.2-5 

The communication interfaces will support processing of closed-loop fare payments at ferry terminals. 

3.2.2-6 

The System will support the offline operation of field devices according to defined business rules and transmit stored 
transaction information as soon as communications are reestablished. 

3.2.2-7 

The communication interfaces will support real-time processing of closed-loop fare payments at rail stations. 

3.2.2-8 

The Program needs the SI to accommodate potential improvements provided by the Agencies over time. 

3.2.3-1 

The System will support the limited writing of data to closed-loop fare media for the purposes of fraud mitigation, 
displaying accurate and timely account information, and risk management. The information written to the fare media 
may include: 

• Recent transaction information (e.g., transaction timestamps) 

• Transit account balance information (e.g., low balance/load indicators) 

• Transit account status information (e.g., passenger type, organizational program, or blocking indicators) 

Data to be written to the media will be determined during design review and subject to Agency approval. 

3.2.3-2 

When network communications are reestablished, the communications interface will support the capability for each 
field device to transmit stored transaction information and receive messages from the back office based on configurable 
prioritization business rules. 

3.2.3-3 

The SI shall provide a non-proprietary method to recover the data on each validator in the event of a device failure. The 
method will not require a network wired or wireless connection, i.e., a separate port or other mechanism for data 
transfer. 

3.2.3-4 

Data will be able to be written to the closed-loop fare media at time of manufacture, loading, and use. All data will be 
secured for both reading and writing using approved cryptography. 

3.2.3-5 

The System will support the distribution of lists to be maintained locally at the field devices and used for fare validation 
and inspection. The lists will be managed within the back office and distributed to the devices via the System 
Management API. 

3.2.3-6 

Any data written to the closed-loop fare media will be used to supplement back office account data, and will be limited 
in nature. The data will be able to be interpreted by the devices with minimal or no business rules logic (i.e., no 
knowledge of fare policies and products will be required). 

3.23-7 

List updates will be distributed to field devices at a frequency of no less than every five (5) minutes and include version 
control to confirm timely and accurate synchronization. 

3.2.4.1-1 

The SI shall implement strong security controls to prevent fraudulent use of the APIs and authenticate all users, meeting 
the baseline outlined by the frameworks described in section 3.1.14. 
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Capability 


The System will be designed using open standards for software design, communications protocols, fare media, and other 
relevant design components. 


The full range of APIs provided by the SI will support all interfaces within the fare collection system, and is not limited to 
the specific APIs described in this section. Any additional APIs that are required will be identified during design review. 
The Program needs the SI to provide Interface Control Documentation (ICD) for each system interface that describes the 
interface and APIs used to support it. 


Each API will be developed using modern architecture and formats (e.g., REST/JSON). The specific architecture and 
format to be used will be identified and agreed upon during design review. 


The Program needs the SI to develop Hypertext Transfer Protocol Secure (HTTPS), or Agency approved modern 
alternative, based functional (e.g., not device- or system-specific) API that support core system functions and enable 
access to those functions for any device or system that requires use of them. Devices and systems may make use of more 
than one API to support required functionality. 


The Program needs the SI to publish full API specifications that document all API calls and the process for making those 
calls, may include: 

• Detailed call descriptions 

• Use cases 

• Call structure 

• Data elements and format 

• Error handling 

• Timing capabilities 

• Use of required security protocols 

• Sample code 


The Program needs the SI to demonstrate use of the API as part of system implementation and testing. The Program 
needs the SI to perform API-specific testing, which will be witnessed and validated by Agency representatives prior to 
Final System Acceptance. Any changes to the APIs as a result of testing will result in the API specifications being updated 
by the SI. 


The Program needs the SI to be responsible for providing the following APIs at a minimum: 

• Fare Distribution API 

• Fare Payment API 

• Fare Inspection API 

• Transit Account Management API 

• Customer Account Management API 

• System Management API 

• Onboard Integration API 

• Central Payment Processing API 

Alternative categorization of APIs may be permitted, as long as the functional capabilities are met and demonstrated. 


The API and Interface Control Documentations (ICD) will be fully owned by or licensed to the Agencies with the right to 
use and distribute the specifications without further approval, license, or payment. 


The Program needs the SI to update the API and Interface Control Documentation (ICD) specifications as necessary 
throughout the warranty and Software Maintenance Agreement terms. 


The SI will provide and publish for Agency use the detailed specifications for all fare media and transaction formats used 
within the System._ 


The System will support the distribution of multiple lists to be maintained locally at the devices and used for fare 
validation and inspection. The lists will be managed within the back office and distributed to the devices via the System 
Management API. 
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Capability 


The open architecture will encompass all media and devices deployed within the System, and include all fare media 
formats, security protocols, authentication requirements, and communications necessary to support critical system 
functions. 


Media list updates will be generated at a configurable interval and include version control. At a minimum the list will be 
updated every 5 minutes._ 


The program needs all APIs that facilitate communication with field devices to be able to accept transactions in an offline 
mode, and accommodate scenarios where a full communication cannot be received within the configured timeframe. In 
these scenarios, risk mitigation strategies will be employed to limit exposure for declined payments and an asynchronous 
response needs to be gracefullv handled. 


The Customer Account Management API will support the querying and management of data maintained within the CRM, 
and will be utilized by all devices and systems that require access to those functions, including but not limited to: 

• Customer service terminals 

• CRM 

• Customer website 

• Customer mobile app 

Not all devices/systems will require or be granted access to all Customer Account Management API functions. 


The Customer Account Management API will support the following functionality at a minimum: 

• Create new customer account 

• Query customer account status and data 

• Modify customer account data 

• Register (e.g., associate) a transit account to a customer account 

• Unregister (e.g., disassociate) a transit account from a customer account 

• Add, update, or remove a funding source associated with a customer account 

• Close a customer account 


The Customer Account Management API will include API calls for the passing of data between the devices/systems and 
the back office to perform all functions. 


The Customer Account Management API will allow devices/systems to create customer accounts within the CRM, and 
associate or disassociate existing transit accounts with those customer accounts. 


The Customer Account Management API will allow devices/systems to query and modify all customer account data, 
including but not limited to name, address, date of birth, phone number, email address, organization and administrator 
contact information, username, password, security questions/answers, funding sources, and program registration details 
(such as RRFP, ADA Paratransit and low income fare programs). 


The Customer Account Management API will allow authorized personnel to close customer accounts. Closing of a 
customer account will not affect the associated transit accounts. Other business rules such as impact on registered 
media, re-opening conditions, and data retention will be finalized during design review. 
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Capability 


The Customer Account Management API will capture all required information to generate a detailed transaction within 
the back office for all functions performed, including at a minimum: 

• Date/time 

• Agency 

• Sales/customer service channel ID 

• Device/system ID 

• Device/system location 

• Operator/administrator ID 

• Fare Media identifier (if associated with a customer account) 

• Transit account number (if associated with a customer account) 

• Customer account number 

• Customer account data 

• Details of action performed 


The Customer Account Management API will return a confirmation of the actions taken by the back office. If any action 
was unsuccessful, a denial and associated reason code will be provided. All response types and error handling will be 
described in detail in the Customer Account Management API specification. 


The Customer Account Management API will support the querying and management of customer account data 
maintained within the CRM. 


The Transit Account Management API will support the querying and management of data maintained within back office 
transit accounts, and will be utilized by all devices and systems that require access to those functions, including but not 
limited to: 

• VMs 

• Customer service terminals 

• CRM 

• Customer website 

• Customer mobile app (as appropriate for customer account type) 

• Agency mobile apps 

Not all devices/systems will require or be granted access to all transit account management API functions. 


The Transit Account Management API will support the following functionality at a minimum: 

• Query transit account status (e.g., associated passenger type, active/inactive, blocked/unblocked) 

• Query fare payment transaction history 

• Query sales transaction history 

• Query adjustment transaction history 

• Enable fare product for autoload (requires funding source in customer account) 

• Generation of fare payment reversal (e.g., cancellation) 

• Generation of sales reversal (e.g., refund) 

• Generation of an account adjustment (i.e., add or remove E-purse value or product) 

• Transfer of balance between two transit accounts 

• Block/unblock fare media, account, or individual fare product 

• Lost, stolen, or damaged fare media replacement (i.e., associate new card with existing transit account) 

• Generation of an opt-out refund (i.e., close account and issue refund) 


The Transit Account Management API will include API calls for the passing of data between the devices/systems and the 
back office to perform all functions. 
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Capability 


The Transit Account Management API will allow devices/systems to query a transit account status and return the sales, 
fare payment, and adjustment transactions that were conducted over a specified timeframe, or a specified number of 
ast transactions. 


The Transit Account Management API will allow devices/systems to setup autoload for an existing fare product. Enabling 
autoload will require a valid funding source to be stored in an associated customer account, and may be performed 
using the Customer Account Management API instead. 


The Transit Account Management API will allow authorized personnel to perform adjustment, reversal, transfer, and 
refund transactions to modifv transit account balances. 


The Transit Account Management API will allow authorized personnel to generate blocking (and unblocking) and 
replacement transactions to close or prevent use of transit accounts, fare media, and fare products. 


The Transit Account Management API will capture all required information to generate a detailed transaction within the 
back office for all functions performed, including at a minimum: 

• Date/time 

• Agency 

• Sales/customer service channel ID 

• Device/system ID 

• Device/system location 

• Operator/administrator ID 

• Fare media identifier 

• Transit account number 

• Details of action performed 


The Transit Account Management API will return a confirmation of the actions taken by the back office. If any action was 
3-9 unsuccessful, a denial and associated reason code will be provided. All response types and error handling will be 
described in detail in the transit account management API specification. 


Using the Transit Account Management API an external system will be able to charge a stored value E-purse for purchase 
of a product. 


Using the Transit Account Management API an external system will be able to determine the balance of stored value in a 
transit account. 


Using the Transit Account Management API an external system will be able to query purchase of a product including the 
location where the product was purchased. 


The Fare Distribution API will support the sale of all available fare media and fare products, and will be utilized by all fare 
distribution devices and systems, including but not limited to: 

• VMs 

• Customer service terminals 

• CRM 

• Customer website 

• Customer mobile app (as appropriate for customer account type) 


The Fare Distribution API will support the following functionality at a minimum: 

• Retrieval of available fare media and associated pricing and expiration dates 

• Retrieval of available fare products, and associated pricing 

• Sale of all fare media types, and creation or activation of an associated transit account 

• Sale of all available fare products (e.g., stored value, passes and multi-ride products), and update of an associated 
transit account 


Fully Conforming 
NonEonforming 
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Capability 


The fare media and products available for sale, and the associated pricing, will be configured and maintained in the back 
office. The Fare Distribution API will return this information upon request from a fare distribution device/system. The 
results provided will be configurable to be specific to the sales channel, device/system location, or individual 
device/svstem making the API call. 

3.2.4.4-4 

Fare distribution devices such as VMs and CSTs will be able to communicate with the back office using the Fare 
Distribution API to enable the creation, activation, and updating of a transit account. 


Unique fare media and/or transit account identifiers will be used securely by the distribution devices/systems and 
passed to the back office to create or activate a new transit account (e.g., in support of new media issuance), or initiate 
the loading of value to an existing transit account. All fare media and product sales will be processed by the back office in 
real-time to enable immediate use bv the customer. 

3.2.4.4-6 

The Fare Distribution API will support the generation of sale and payment transactions within the back office by 
capturing all information required to appropriately record the sale, including at a minimum: 

• Date/time 

• Agency 

• Sales channel ID 

• Device/system ID 

• Device/system location 

• Fare media identifier 

• Transit account number 

• Product(s) sold 

• Payment amount(s) 

• Payment type(s) 

The Fare Payment API will support the sale of multiple products (e.g., fare media and value) in a single transaction with a 
single payment, and the use of multiple payments (e.g., split payments) in a single sales transaction. 

3.2.4.4-7 

The Fare Distribution API will return a confirmation of the actions taken by the back office to complete a sale. If the sale 
was unsuccessful, a denial and associated reason code will be provided. All response types and error handling will be 
described in detail in the fare distribution API specification. 


The Fare Payment API will support the processing of closed-loop fare payments across all Agencies and modes using all 
supported fare media and fare products, and will be utilized by all fare payment devices, including but not limited to: 

• Onboard validators 

• Wayside validators 

• Customer mobile app - payment presentation 

• Agency mobile app - fare validation 


.5-2 


The Fare Payment API will include API calls for the passing of data between the fare payment devices and back office to 
initiate a fare payment transaction, which will result in a fare calculation being performed and processing of a payment 
against a transit account._ 


Fully Conforming 
NonEonforming 
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The Fare Payment API will support the generation of fare payment transactions within the back office by capturing all 
information required to calculate and appropriately record the payment, including at a minimum: 

• Date/time 

• Agency 

• Vehicle/station ID 

• Operator ID (bus and mobile only) 

• Device ID 

• Stop ID 

• Geolocation information (bus and mobile only) 

• Pattern (bus and mobile only) 

• Block (bus and mobile only) 

• Route (bus and mobile only) 

• Run (bus and mobile only) 

• Direction/platform 

• Fare media identifier 

• Transit account number 

• Other data encoded to the media (e.g., passenger type) 

• Authorization mode (e.g., online or offline) 


The Fare Payment API will return a confirmation of the actions taken by the back office to complete a payment and 
account status information, including at a minimum: 

• Payment status (e.g., success or failure) 

• Transit account passenger type 

• Fare product used 

• Fare charged 

• Remaining balance 

• Transfer time remaining 

If the payment was unsuccessful, an associated reason code will be provided. All response types and error handling will 
be described in detail in the fare payment API specification. 


The Fare Payment API will support the passing of a pre-calculated fare to support programs such as Washington State 
Ferries, where third-party devices or systems may calculate the amount due. The back office will process pre-calculated 
fare transactions based on the fare structure configured for the associated mode or customer. The request passed will 
include location. 


Using the Fare Payment API an external system will be able to query the use of a product (such as a transportation 
connection) including location._ 


The Fare Inspection API will query closed-loop transit accounts to support the inspection of fares paid across all Agencies 
and modes using all supported fare media and fare products, and will be utilized by the mobile fare inspection devices. 


The Fare Inspection API will include API calls for passing data between the Mobile Fare Inspection application and back 
office to initiate a fare inspection transaction, which will result in confirmation or denial of payment made using a closed- 
loop transit account and open payments using all supported payment network branded cards and NFC-enabled devices. 


Unique fare media and/or transit account credential identifiers will be securely captured by the mobile fare inspection 
devices and passed to the back office to perform a fare inspection. The back office will query transit account ride history 
and use Aeencv-defined business rules to determine fare oavment status in real-time. 
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All fare inspections will result in a recorded transaction. The Fare Inspection API will support the generation of 
transactions by capturing all information required to determine the status of a fare payment and appropriately record 
the inspection, including at a minimum: 

• Date/time 

• Agency 

• Vehicle/station ID 

• Device ID 

• Stop ID 

• Geolocation information 

• Pattern (bus inspection only) 

• Block (bus inspection only) 

• Route (bus inspection only) 

• Run (bus inspection only) 

• Direction/platform 

• Fare media Identifier 

• Transit account number 

Other data encoded to the media (e.g., passenger type) 


The Fare Inspection API will return fare payment status information, including at a minimum: 

• Payment status (e.g., valid or invalid) 

• Account passenger type 

• Fare product used (if valid tap is found) 

• Fare charged (if valid tap is found) 

• Transfer time remaining (if valid tap is found) 

• Account balance 

• Fare payment transaction history 

If the payment is determined to be invalid, an associated reason code will be provided (e.g., no tap, blocked card). All 
response types and error handling will be described in detail in the Fare Inspection API specification. 

3.2.4.7-1 

The System Management API will be utilized by all devices deployed within the System, including but not limited to: 

• Onboard validators 

• Wayside validators 

• Driver display units 

• Vending machines 

• Customer service terminals 

• Mobile fare inspection devices 

• Mobile fare validation devices 

3.2.4.7-2 

The System Management API will support the passing of data between the devices, the Asset Incident Management 
application (AIM), and the System Manager to enable the monitoring of system performance during operations. The 
device events and alarms reported via the System Management API will provide enough detail to support proactive 
device maintenance at the module-level, and support accurate reporting on all system performance capabilities. The 
System Management API will not preclude being interfaced with a decision support system in the future. 


3.2.4.7-3 


The System Management API will support the passing of data between the System Manager and devices to enable 
remote control and issuance all commands supported for each device type. All commands will be able to be issued and 
executed in real-time._ 


Fully Conforming 
NonEonforming 
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The System Management API will support the real-time distribution of device software and configuration parameter 
updates. Device configuration will include real-time updates to any positive and negative lists maintained locally at the 
devices. Updates will be distributed on an increment-basis so that only updates since that last time stamp/version 
received bv an individual device are transmitted. 


A universal System Management API will be created and used wherever possible; however, the SI may create device- 
specific System Management APIs or calls as necessary._ 


All configuration parameters distributed to the devices, including positive and negative list updates, will be distributed 
using the Sl-orovided Svstem Management API. 


The Onboard Integration API will be utilized by the onboard validators to exchange information with the CAD/AVL 
system to support single sign-on. 


The Onboard Integration API will support the capture of operator login and route data from CAD/AVL system, including 
but not limited to: 

• Operator ID 


The onboard validator will append this information to all fare payment transactions generated by the device. 


The Onboard Integration API will support the capture of geolocation data from CAD/AVL system geolocation data, 
including but not limited to: 

• GPS coordinates 

• Stop ID 

The onboard validator will append this information to all fare payment transactions generated by the device. 


The Onboard Integration API will be designed such that it is vendor agnostic; however, the SI will partner with each 
Agency's existing CAD/AVL supplier and meet all system-specific capabilities._ 


The program needs provide a Central Payment Processing API, including all required security protocols, to connect the 
back office to the payment processor so that gatewav and processor can be switched without reprogramming. 


The SI supplied and maintained interface to the payment processor will be designed to support the addition of open 
payments in the future. In particular, the architecture will support a real time connection from field validators to the 
processor through the Fare Pavment API. 


The program needs to publish specifications for all transactions generated and used within the System but not already 
covered bv the required API. 


Transaction specifications will include detailed descriptions of the transaction structure, data elements, and data 
formats, and identify all devices and system that generate and consume the described transactions._ 


Transaction formats will be based on published standards wherever possible, including those used to interface with 
commercial software packages, such as the Sl-provided CRM, financial management, and reporting systems. 


The transaction formats will be fully owned by or licensed to the Agencies, including the right to distribute the 
specifications to third-parties without further approval, license, or payment. 


The onboard validator and DDU will connect to the mobile access router via Ethernet. 


Onboard validators will connect with onboard mobile network to access the back office system. 


If cloud based, or hosted, transferring data between systems will be by a secure protocol. 


Fully Conforming 
NonEonforming 












































Capability 

Number 


3.2.6-2 


3.2.6-3 


3.2.6-4 


3.2.6-5 


3.2.6-6 


3.2.6-7 


3.2.6-8 


3.2.6-9 


3.2.7-1 


3.2.7-2 


3.2.7-3 


3.2.7-4 


3.2.7-5 


Capability 

If the back office is to be hosted through a cloud-based hosting service (AWS, Rackspace, etc.) it will be subject to 

approval by the Agency. All hosted data will be owned and accessible by the Agencies. _ 

If the SI hosts the System, the Program needs the SI to provide two (2) separate, identical, and fully functional 
production back office installations, each able to handle 200% of the anticipated peak processing load, and scalable to 

support up to 400% of the anticipated peak processing load. _ 

If the SI hosts the System, the two sites will process transactions in parallel in an active-active, load balanced 
configuration in order to optimize performance and safeguard that if one (1) system fails, or goes into a degraded mode, 
the second system will automatically take over all processing with no downtime. The System will be designed such that a 
failure at one (1) site will not result in a significant degradation of system performance. This architecture will also 

support the execution of rolling upgrades across the two (2) sites with no downtime. _ 

If a hosted model is chosen the Program needs the SI to install, configure, and test the two fully redundant back office 
systems in the production environment. These systems will be installed at two designated, geographically separated 

locations identified and hosted by SI. _ 

For hosted or cloud-based solutions (i.e., software components reside and execute on Si's infrastructure), mechanisms 

must be in place to keep ORCA data segregated from other non-ORCA data. _ 

If the SI hosts the System, the mirrored installations will include all customer-facing and operation-critical systems, 
including but not limited to: 

• ATP 

• CRM 

• System Manager 

• FMM 

• Financial Management 

• Central Payment 

• Configuration and Change Management 

• Asset Incident Management 

• Tariff Management 

• Web Servers (e.g., supporting customer website) 

Each installation will include all application servers and databases necessary to independently support each back office 
system. 

All transaction data will be protected against loss whether hosted or cloud based. If the SI hosts the System, each 
identical and independent installation will be equipped with the appropriate hardware, software, and procedures to 

mirror data between the two sites in real-time (e.g., simultaneous writes). _ 

If the SI hosts the System, load balancing, automated failover, and data mirroring between the two sites will be provided 

using COTS hardware and software solutions. _ 

The SI shall provide a system that offers sufficient availability to protect against data loss and system failure. 

The SI shall develop and submit for approval a disaster recovery plan that will take effect in the event of a catastrophic 
event or system failure that impacts one or both hosting sites. The Disaster Recovery (DR) plan will conform to the 
required service level agreement and be consistent with the Business Continuity Plan and recovery time capabilities that 

will be provided by the Agencies. _ 

In the DR Plan, the SI shall fully document all procedures to restore system operations. 

The Program needs the SI to propose a physical and logical architecture (e.g., virtualized servers, spare load balancers, 

etc.) that meets all redundancy capabilities for Agency review and approval at design review. _ 

The disaster recovery plan will contain detailed procedures to be followed to restore the System to full operation 
following a disaster or failover event, including the complete resynchronization of data between the two sites. Agency 
KPIs including recovery time objectives and recovery point objectives will be part of the disaster recovery plan. 
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Fully Conforming 

NonBonforming 

Comments 

3.2.7-6 

Means will be provided in the System design to support complete recovery from the loss of any system components at 
any point during operation. 

X 



3.2.7-7 

Program needs the SI to identify the resources (e.g., people, systems, communications, etc.) that must be committed to 
implement the disaster recovery plan. 

X 



3.2.7-8 

The Disaster Recovery Plan will provide recovery procedures from disasters that have varying levels of impact to system 
operations and detail the steps to be taken to recover from such disasters. 

X 



Section 3.3 System Integration Services 


3.3.1-1 

The integration of Transportation Connections (additional modes) through API will allow for discounted or free transfers 
between additional modes reported by external systems and primary modes such as fixed route services. 

X 



3.3.1-2 

The Program needs the SI to take the lead role in working collaboratively with third-parties to integrate legacy systems as 
necessary to support the capabilities in this SOW and ultimately be responsible for system performance. 

X 



3.3.2-1 

The SI will provide an API Management Plan for approval during design review. 

X 



3.3.2-2 

The API Management Plan will be compliant with the control baseline required by the ISMS. 

X 



3.3.2-3 

The API Management Plan will include a process for onboarding before connecting an external device or system to the 
next gen ORCA back office and methods for approving all new versions of devices, firmware, or software prior to their 
connection to the System. 

X 



3.3.2-4 

The API Management application will include consumer certification and key management. 

X 



3.3.2-5 

The API Management application will include a service registry with details of the API consumers and contact 
information for the developers of the consumers. 

X 



3.3.3-1 

The SI shall be responsible for integration of the validator with each Agency's existing CAD/AVL or similar onboard 
system to support transfer of work status information (route/run/trip) and geolocation data. 

X 



3.3.3-2 

The onboard modules will be able to communicate over Ethernet and TCP/IP, at a minimum. The communication 
interface to be used will be determined during design review and must provide adequate support for all system 
capabilities and integrations. Additional communication standards may be used such as SAE Vehicle communications 
standards (such as J1708/1939), Bluetooth, USB, etc. 

X 



3.3.3-3 

The SI shall be responsible, in collaboration with INIT, the KCM CAD/AVL vendor, for all development, testing, and 
deployment of the module for exchange of data with the KCM CAD/AVL system. 

X 



3.3.3-4 

A detailed Interface Control Document (ICD) detailing message formats and contents, procedures, interfaces, and 
transport protocols will be provided for the onboard systems integration. 

X 



3.3.3-5 

The onboard validator will capture location data generated by the CAD/AVL system, including: 

• Raw Global Positioning System (GPS) coordinates 

• Stop ID 

The geolocation data will be included in every fare transaction generated by the validator. 

X 



3.3.3-6 

The design for the exchange system for data with the KCM CAD/AVL system will be a subject of the design review 

process. 

X 



3.3.6-1 

All functional and longterm data will be duplicated in an external system, the Data Access and Reporting platform 
(DARe) which will be initially deployed prior to the main system by a separate vendor. The design and deployment of the 
DARe is not a part of this contract. 

X 



3.3.6-2 

The SI shall be responsible for building and testing a module to transmit data to the DARe, in collaboration with the 

DARe vendor and the Agencies. 

X 



3.3.6-3 

The Program needs the SI to work with the DARe vendor to design a transmission module which is secure and reliable. 
The transmission system will be subject to the System reliability and recovery metrics for the SI. 

X 



3.3.6-4 

The Program needs the SI to work with the DARe vendor to design, build and test the link from the next gen ORCA back 
office to the DARe. 

X 





































Capability 

Number 

Capability 

Fully Conforming 

NonBonforming 

Comments 

33.6-5 

Customer and transit account identifiers will be protected with an accepted approach, determined during design, for 
transmission to the DARe. 

X 



33.6-6 

The data transmitted to the DARe will be a subset of all the data, focused on the data required for long term reporting. 
The data to be transmitted will be selected as part of the design review process. 

X 



33.6-7 

The data transmitted to the DARe will not include any data that would put the DARe in PCI scope. The DARe will be 
compliant with the control baseline required by the ISMS. 

X 



33.6-8 

The data transmission to the DARe will occur at least once a day. 

X 



33.6-9 

The Program needs the SI to be responsible, in collaboration with the DARe vendor, for all development, testing, and 
deployment of the module for transmission of data to the DARe. 

X 



3.3.6-10 

The design for the transmission module for data to the DARe will be a subject of the design review process. 

X 



33.7-1 

Using the Fare Distribution API an external retail system will be able to create a transit account and add value to the E- 
purse in a transit account. 

X 



33.7-2 

The SI shall work collaboratively with the retail contractor to provide the necessary equipment, documentation, and 
services to support the successful completion of System Integration Testing. 

X 



33.7-3 

The sale of a next gen ORCA card by a retail merchant will initiate the automatic creation of a transit account within the 
next gen ORCA back office. 

X 



33.7-4 

The transaction data will be fully compliant with the control baseline required by the ISMS for the handling of customer 
Pll. 

X 



33.7-5 

Transaction data elements will be defined by the SI during design review. Transaction data elements will include at a 
minimum: 

• Card type 

• Unique card identifier 

• Transit account number 

• Date and time of transaction 

• Transaction type 

• Transaction value 

• Beginning transit account balance 

• Ending transit account balance 

• Merchant ID 

• Merchant name 

• Merchant location 

X 



33.7-6 

Retail network provisioning and testing will be completed in coordination with the SI to support operation of a fully 
functional retail network no later than the commencement of next gen ORCA revenue service. 

X 



33.7-7 

Program needs the SI to work collaboratively with the retail contractor to develop test scripts that together accurately 
and completely confirm all features and functionality of contractor's retail network system. 

X 



33.7-8 

Program needs the SI to work with retail contractor to incorporate retail network functionality into the Agency test 
facility. 

X 



33.7-9 

The retail network will allow a merchant to reverse a transaction prior to authorization of the transaction with the next 
gen ORCA System. Authorization and provision of next gen ORCA refunds will be the responsibility of the Agencies and 
the next gen ORCA System. Retail network transaction reversals will result in no charge to the customer or the Agencies. 

X 



3.3.7-10 

Agency test facility will be connected directly to a contractor-specified payment processor to fully test the processing of 
next gen ORCA purchases using credit/debit as a form of payment. 

X 



3.3.7-11 

Program needs the SI to work closely with the retail contractor throughout the Field Integration Test to help resolve 
issues and implement fixes on the retail network identified during testing. 

X 


























Capability 

Number 


Capability 


3.3.8-1 

The SI shall be responsible for all development, testing, and deployment of the module for exchange of data between 
the back offices 

3.3.8-2 

The Program needs the SI to design, build, and test the link from the next gen ORCA back office to the Legacy ORCA back 
office 

3.3.8-3 

The design for the exchange of data with the Legacy ORCA System will be a subject of the design review process. 

3.3.9-1 

The System will include a King County Metro Access pass for ADA Paratransit which can only be purchased by customers 
marked in the System as eligible. 

3.3.9-2 

The list of Access eligible customers will be imported into the System on a regular basis from a .csv file. 

3.3.9-3 

The System will provide pass sales information for paratransit customers that can be uploaded to Agency paratransit 
databases. 

3.3.9-4 

The System will include the ability to create an Agency-specific pass product that can only be purchased by customers 
marked in the System as eligible. 

3.3.10-1 

When next gen ORCA customers pay vanpool fares via the customer website and/or mobile app, the CRM application 
will capture relevant transaction information for tracking and reporting. This will include such elements as: payment 
date, operating Agency, customer account name, customer name, transit account number, vanpool or group ID number, 
fare amount paid, fare period, and receipt number. This information can be reported on through the back office. 

3.3.10-2 

The System will allow next gen ORCA account holders to pay vanpool fares via the customer website, CRM, or mobile 
app. The amount of the fare is entered by the customer and will vary by customer. There will be configurable minimum 
and maximum amounts. 

3.3.10-3 

When a next gen ORCA account holder pays their vanpool fares via the customer website and/or mobile app and CRM a 
receipt will be generated and optionally emailed or texted to the customer. 

3.3.10-4 

Revenue from the vanpool fare payment and purchase of the joint transit and vanpool pass will be segregated and 
reported separately by Agency. 

3.3.10-5 

The System will allow the creation of Agency-specific and regional joint Transit and Vanpool Pass Products available for 
addition to any transit account. 

3.3.10-6 

The available periods for payment of vanpool fares will be configurable. 

3.3.11-1 

The System will support the addition of new agencies, including fare rules that are part of the existing design. 

3.3.11-2 

The Agencies will be able to add new transportation connections, modes and products (e.g., parking) with unique fare 
pricing and all the configurability of existing modes and products without additional development. 

3.3.11-3 

Transportation Connections (additional modes) will be supported in the System through APIs that allow third party 
developers of external applications to communicate with the System in order to manage fare products, transit accounts, 
and report transactions. 

3.3.11-4 

The System will support the addition of a minimum of five (5) additional agencies. 

3.3.11-5 

The System will provide scalable framework to support the growth in users and data inherent in adding agencies. 

3.3.11-6 

The System will be capable of integrating with Kitsap Fast Ferries reservation system in Phase II. 

3.3.11-7 

All agencies added after the initial implementation will use the System's user interfaces, process flows, and business 
rules as designed during the initial implementation. 

3.3.11-8 

Additional agencies will be able to have revenue sharing and apportionment turned on or off according to the existing 
apportionment rules. 

Section 4 Field Devices & Equipment 

Section 4.1 Common Capabilities 


All equipment design, including dimensions, mounting options, and installation placement will be subject to review and 
approval by the Agencies._ 


Fully Conforming 
NonEonforming 





























































Capability 

Number 











Capability 


All customer-facing equipment and applications including website will provide a coherent customer experience, with 
similar look and feel across all modes' validators and VMs. Agency and designated representatives will participate in a 
design review with the SI to define the customer experience for both hardware and software. 


All customer-facing equipment will be designed to adhere to the aesthetic standards of the Agencies, with consistent 
cross-platform branding. The Program needs the SI to submit designs for review and approval during design review. Final 
equipment design, including interface display, lettering, lights, colors, tactile feedback, brightness, graphics, animation, 
screen savers, surface texture, component size and height, and hardware will be subject to Agency approval. 


System equipment displays (including the entire surface of the display for the VM), graphics, signage, and all other 
instructions, labels, and information contained on the equipment will be visually readable within all common positions X 
from a customer point of view. 


The Program needs the SI to deliver the latest generation device manufactured by the OEM. If a newer generation device 
is released following design review, but prior to device procurement, the Agencies shall have the option to upgrade to X 
the newer device. 


All equipment will meet the applicable hardware security capabilities. 


The SI shall provide PCI compliant hardware and software for payment processing. The PCI architecture will be designed 
to limit increases in PCI scope, and will be reviewed and approved during design review. 


All fare equipment will satisfy all applicable common hardware design capabilities including: 

• Service-proven design 

• Nonproprietary technology 

• Supply and availability 

• Materials and workmanship 

• Maintainability and serviceability 

• Operating environment 

• Meet or exceed ADA compliance capabilities 
Code and regulation compliance 


Equipment components will be designed, built, and installed to withstand the harsh operating environment. 


All equipment will meet the applicable software security capabilities described in this SOW. 


Equipment software and firmware will satisfy the common design capabilities in Section 3.1 including: 

• Service-proven design 

• Nonproprietary technology 

• Software design principles 

• Licensing and ownership 

• Accessibility and ADA compliance 

• Code and regulation compliance 

• Information security 
Fraud prevention 


All equipment will employ the most current version of a COTS operating system at the time of production. The operating 
system will be capable of performing all tasks necessary to support the equipment and its applications, including the ^ 
capability to multitask, manage memory, maintain performance without degradation, and communicate with the back 
office in real-time. 


All equipment will maintain local transaction and data records in non-volatile memory in the event that communications 
to the back office is unavailable. Local records will not be deleted until they have been confirmed as received and X 

recorded by the back office. 
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Number 







Capability 


The design of the System will provide a mechanism to recover transactions or other data stored on faulty equipment 
that has not been transmitted to the back office. 


All customer-facing system equipment will incorporate a test mode. In this mode, the equipment will have full 
functionality and process only test media. Test transactions will be segregated in reporting from revenue transactions. 


The System Manager will publish fare media positive and negative lists generated and used by the account-based 
transaction processor, and distribute to devices to support fraud avoidance and risk mitigation. Positive and negative list 
updates will be published no less than every five (5) minutes and include version control to confirm timely and accurate 
synchronization. The frequency will be configurable. 


All equipment will receive date/time, configuration, and list updates (as applicable) from the back office automatically at 
startup and as necessary. 


Equipment software and configuration updates, including all valid and invalid card lists, will be managed through the 
Configuration & Change Management application. 


The equipment software and applications will accommodate next gen ORCA's existing fare structure and potential fare 
policies described in the Fare Policy section (6.2.5) and Appendix 3 of this SOW._ 


Equipment will receive configuration and software updates when available from the back office. The equipment will not 
commence updating software until it has received and verified the complete update. If any updates require a reboot, 
they will occur during non-operating hours, unless specifically approved bv authorized service staff. 


Each software update will have a unique version number and include an activation date and time if applicable. Updates 
will be able to be downloaded and applied at that activation time, or activated immediately after download and 
verification is confirmed. 


The software update download process will not interrupt normal equipment operations, or cause data or file corruption 
if communication is lost. The process will recover from such loss and complete the download without issue. 


Section 4.2 Onboard & Wayside Validators 


The validators will support validation of ISO 14443 compliant contactless smart cards. 


Validators will accept all fare media included in the System design, including the following fare media at a minimum: 

• Agency-issued Extended Use (EU) fare media including Legacy ORCA fare media 

• Credentials presented by the customer mobile app using NFC technology 


Validators will be PCI- and EMV-certified for the acceptance of bank-issued contactless credit and debit cards using all 
common formats based on the latest version of the standard at the time of Final System Acceptance. Validator will be 
capable of re-certification with newer versions of the PCI and EMV standards via software upgrades as necessary. 


If the onboard or wayside validator is purchased from a third-party, the Program needs the SI to deliver the latest 
generation device manufactured by the OEM. If a newer generation device is released following design review, but prior 
to device procurement, the Agencies shall have the option to upgrade to the newer device. 


An alternate means of downloading data from the validator will be provided for instances where there is a failure of the 
wired or wireless communication. 


Validators will support a minimum of two (2) Secure Access Modules (SAMs) to facilitate acceptance of multiple fare 
media formats and the replacement of security keys, should compromise occur._ 


Validators will have at least three (3) spare universal serial bus (USB), or Agency approved equivalent, ports to support 
removable memory, SAMs, or future connection of ancillary devices, such as a barcode validator. 


Validators will include sufficient embedded storage to hold at least 30 days of fare payment transactions, and all risk 
mitigation lists as determined necessary during design review. 



X 















































Capability 

Number 

Capability 


Validators will support expandable storage in a common, commercially available format (e.g., USB drive, compact flash, 
secure digital, etc.) that can be quickly and easily swapped or expanded without modification to the rest of the device 
components. 

4.2.1-10 

Onboard and wayside validator equipment will comply with all applicable hardware and software security requirements 
contained in this scope of work. 

4.2.1-11 

All onboard and wayside validator equipment will comply with the applicable accessibility and ADA requirements 
contained in this SOW. 

4.2.1-12 

The validator will be compliant with and support all open payment contactless standards, including but not limited to: 

• Apple Pay 

• Android Pay 

• Samsung Pay 

• VISA payWave® 

• MasterCard PayPass® 

• American Express ExpressPay® 

• Discover Zip® 

• Contactless EMV 

4.2.1-13 

Validator software design will allow for accepted media formats, including Agency defined formats, to be enabled and 
disabled via configurable parameters. 

4.2.2.1-1 

The validator will be simple and compact, as determined during system design and testing, while providing the 
functionality in this section. 

H 

Validators will be rugged and function under extended severe environmental conditions including: direct sunlight, 
moisture, dust/grit/sand, humidity, electrical storms, exposure to urban environment, and the range of elevations and 
altitudes in the operating region. 

n 

The validator housing will be resistant to corrosion, abrasion, scratching, impacts, and vandalism, and withstand 
standard bus cleaning materials. Validator housing color and finish will be such that it minimizes reflection and is highly 
resistant to fading, cracking, and peeling. 

4.2.2.1-4 

All validator corners will be rounded, and there will be no exposed bolt heads, nuts, sharp edges, or cracks on outside 
surfaces. The validator display will be flush-mounted in the housing. 

4.2.2.1-5 

Covers on the validator housing for accessing modules and subassemblies will be secured with mechanical locks and keys 
that are not readily duplicated nor readily available to the public, and uniquely serialized. 

m 

The Program needs the SI to work with Agency staff to install all mounting brackets, special hardware, electrical and 
communication wiring and service loops, and terminations/connections required for the installation of Sl-provided 
onboard equipment. To the extent possible existing wiring and hardware will be reused as approved by the Agencies. 

4.2.2.2-2 

The Program needs the SI to work with Agency staff to install and perform commissioning testing on all Sl-provided 



onboard equipment on Agency vehicles. 

,2.2.2-3 

Onboard validators will be installed on each bus such that the validator will be in proximity to the vehicle door(s) and will 
be positioned so that a customer may easily present fare media for payment upon boarding the bus. 

,2.2.2-4 

When installed, the onboard validator will not obstruct the operator's view out the vehicle windows, and will not cause 
glare on the windshield during bright sun conditions or at night with the vehicle interior lights off. 

,2.2.2-5 

The onboard and wayside validator and components will be securely mounted using stainless steel hardware in a 
location and manner that is safe for customers and operators. 

,2.2.2-6 

Onboard validator mounting will not interfere with maintenance of other onboard bus systems and components. 

,2.2.2-7 

All required mounting hardware and brackets for each bus type and wayside installation will be provided by the SI. 


Fully Conforming 
NonEonforming 
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Number 

Capability 

Fully Conforming 

NonBonforming 

Comments 

4.2.2.2-8 

All validator components, cabling, installation methods, and mounting will be prototyped on each bus/fleet type and 
subject to written approval by the Agencies before installation. 

X 



4.2.2.2-9 

The mounting design will enable the quick and simple removal of the validator by authorized maintenance personnel as 
determined during system design and testing. 

X 



4.2.2.2-10 

The Program needs the SI to work with Agency staff to install and perform commission testing on all wayside validators 
and mounting systems at Agency transit locations. The Program needs the SI to work with Agency staff to provide and 
install all cabling (from stub up), connectors, and hardware necessary to properly install and secure the equipment in its 
planned location. 

X 



4.2.2.2-11 

The Program needs the SI to provide all wayside validator support structures, such as pedestals, mounting poles, and 
mounting brackets, as needed. Use of existing mounting pedestals or stanchions to support wayside validators will be 
subject to Agency review and approval. 

X 



4.2.2.3-1 

The onboard validators will receive 12 or 24 VDC power through a circuit breaker assigned specifically to the onboard 
validator. External converters or power conditioners may be used with Agency approval. 

X 



4.2.2.3-2 

The onboard and wayside validators will be designed to operate using Power over Ethernet (PoE). PoE usage will be 
confirmed during design review. 

X 



4.2.2.3-3 

When bus power is turned off, the onboard validator will remain powered for a configurable time to allow completion of 
transmission of any and all data files. 

X 



4.2.2.4-1 

Onboard validators will contain an Ethernet port that enables connection to existing cellular/Wi-Fi-enabled mobile 
access routers installed on buses. The mobile access routers will serve as primary means of real-time off-board 
communication with the back office. 

X 



4.2.2.4-2 

Wayside validators will be designed with an Ethernet port that enables real-time connection to the back office. 

X 



4.2.2.4-3 

Onboard validators will include Wi-Fi (802.11a/b/g/n/ac/i/r) communications to enable integration with other systems, 
exchange of non-critical data at designated locations, and sharing of data connections onboard. 


X 

The integrated WiFi does not support 802.11ac. The ac standard helps facilitating applications with 
the need for very high data throughput. All data transmitted from and to the validators are small in 
size. Therefore the ac standard is not critical. The integrated WiFi does support 802.11a/b/g/n/i/r. 

4.2.2.4-4 

If additional communications components are required, all such components will be mounted in a secure and sturdy 
enclosure, with the location and function approved by the Agencies. 

X 



4.2.2.5-1 

A customer-facing contactless smart card validator will be installed in the onboard and wayside validators to read, write 
to, and validate contactless media presented by customers. The validator will have write capabilities as per risk 
mitigation strategies defined in Section 3.2.3. 

X 



4.2.2.5-2 

Validators will include full color displays that support adjustable brightness, contrast, and refresh rate that can be easily 
read, as determined during system design and testing, under any combination of ambient lighting, including direct 
sunlight and night-time operation. 

X 



4.2.2.5-3 

Validator color displays may be adjacent to or directly in front of the contactless validator. In either case, the tap area 
will be easily identified and reachable by customers. 

X 



4.2.2.5-4 

The validator display will be clearly visible, as determined during system design and testing, in all forms of ambient light 
on the bus and viewable at a minimum angle of 45 degrees from the display. 

X 



4.2.2.5-5 

The validator display will be capable of partial or full video or animation. The animations may be used to indicate fare 
feedback, relevant customer action, or other general information. Video or animation files will be able to be updated 
remotely, or installed via removable memory by maintenance staff. 

X 



4.2.2.5-6 

Validators will include an audio interface and speakers for customizable audio feedback, including varying tones and full 
speech. Audio feedback types will be able to be configured and updated remotely. It will be in compliance with or 
exceed all applicable accessibility and ADA requirements. 

X 



4.2.2.5-7 

The decibel levels of the tones on the validators will be programmable locally and remotely, and the emitted tones will 
be capable of being distinguished up to eight (8) feet away in its operating environment. 

X 



4.2.2.5-8 

Onboard and wayside validators will include at least three (3) colors (green, yellow, red) of visual annunciation that can 
be configured to provide feedback, especially for reduced fare payments, on payment and device status. 


X 

Validation status is shown on the color display. 
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Number 


Capability 


Onboard and wayside validators will generate, store, and transmit a discrete data record for each transaction and/or 
validation performed. 


Each onboard validator transaction record will be unique and will include the following information, at a minimum: 
• Date and time 


• Operator ID 

• Bus Stop ID 

• Geolocation information (GPS data) 

• Route number 

• Run number 

• Block number 

• Media type 

• Card number 

• Transit account number 

• Passenger type (e.g., adult full fare, youth, senior, disabled) 

• Action performed 

• Fare instrument or product used (where applicable) 

• Transaction value (where applicable) 

• Transaction result (e.g., success, failure) 

• Transaction ID 

Transaction records details will be finalized during design review. 


Each wayside validator transaction record will be unique and will include the following information, at a minimum: 

• Date and time 

• Device ID 

• Location ID 

• Route number (where applicable) 

• Media type 

• Fare media number 

• Transit account 

• Passenger type (e.g., adult full fare, youth, senior, disabled) 

• Action performed 

• Fare instrument or product used (where applicable) 

• Transaction value (where applicable) 

• Transaction result (e.g., success, failure) 

• Transaction ID 

Transaction records details will be finalized during design review. 


Any offline payment validation will be recorded as such in the transaction data, so that offline transactions can be easily 
identified and tracked. 


All validators will provide audit register counts for purposes of data tracking and analysis. The audit registers will store 
counts of specific events in non-volatile memory and will not be able to be modified or erased. 





















Capability 

Number 

Capability 

Fully Conforming 

NonBonforming 

Comments 

4.2.3.2-2 

The audit registers will maintain counts of the following events as applicable: 

• Total validation counts 

• Passenger type counts 

• Count of approved transactions 

• Count of denied transactions 

• Count of read failures 

• Fare products validated (where applicable) 

• Fare value deducted (where applicable) 

Final audit register events will be determined during design reviews. 

X 



4.2.3.3-1 

Onboard and wayside validators will provide real-time status of device events and alerts reported though the System 
Manager. The onboard and wayside validators will also maintain local event and alert logs in the event that 
communications to the back office are unavailable. 

X 



4.2.3.3-2 

In addition to transmitting real-time events and alerts, the validator will transmit periodic "heartbeat" messages that 
confirm communication with the back office and basic status. The "heartbeat" frequency will be adjustable. 

X 



4.2.3.3-3 

At a minimum, onboard and wayside validators will generate, store, and forward to the back office an event record for 
each of the following events with their corresponding date/time: 

• Power on 

• Power off 

• Operator login and logout 

• Route changed 

• Back office communications failed/restored 

• Maintenance parameter changed 

• New software received/activated 

• New configuration data received/activated 

• New list received/activated 

• Anti-virus definitions and security updates downloaded 

• Internal clock reset 

• Validator clock error 

• Data memory near full/full 

• Validator "heartbeat" check 

Final event records will be determined during design review. 

X 



4.2.3.3-4 

The onboard and wayside validator will have capacity to store a minimum of three (3) months of local event and alert 
data. 

X 



4.2.4-1 

Onboard and wayside validators will be able to accept fare payments in an offline mode, and accommodate scenarios 
where a full authorization cannot be received within the required configured timeframe. In these scenarios, risk 
mitigation strategies will be employed to limit exposure for declined payments. 

X 



4.2.4-2 

Upon power up, the onboard validator will be operational and ready for revenue service within three (3) minutes. It will 
remain operational until a configurable time after power off, subject to normal operating conditions. 

X 



4.2.4-3 

The onboard validator will require a valid logon to function. The bus operator will be able to present an employee ID 
card to the validator to initiate a default login. 

X 



4.2.4-4 

The bus operator will be able to present a properly configured employee ID card to the validator to initiate a login. 

X 



4.2.4-5 

The onboard validator will interface with the MAR to perform real-time communication with the ATP for the processing 
of fare payments using the Sl-provided Fare Payment API. 

X 



4.2.4-6 

After successful logon, the onboard validator will automatically and continuously poll for all supported media formats. 

X 
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Number 

Capability 

4.2.4-7 

The onboard and wayside validator will support an anti-collision algorithm to support that payment is only accepted 
from a single piece of media when multiple valid pieces of media are presented. 


Prior to transmitting a fare payment transaction to the ATP, the onboard and wayside validator will perform local fare 
media validity checks, including checks against any locally maintained positive/negative lists, as deemed necessary for 
security and the efficient processing of transactions. 


The wayside validator will be equipped with a real-time communications interface to the ATP for the processing of fare 
payments using the Sl-provided Fare Payment API. 

4.2.4-10 

The transaction response from the ATP will include: 

• Validation result 

• Fare product used 

• Fare amount charged 

• Balance remaining 

• Fare product expiration date 

• Fare product remaining rides or days 

• Passenger type 

• Transfer time remaining 

• Low balance warning (threshold to be configurable) 

• Time-based pass expiration warning (threshold to be configurable) 

The final list of data elements to be included in the ATP response will be established during system design. Results to be 
displayed on the validator full color display will be determined during design review. Results will be configurable, set by 
downloadable configuration parameters from the back office. 

4.2.4-11 

Fare validation results will be displayed to the operator through the integrated driver display unit. The driver may be 
shown additional fare payment details that are not shown to the customer as determined and approved during system 
design. 

4.2.4-12 

Onboard and wayside validators will provide a payment result, including writing required data to the fare media, within 
500 milliseconds of valid fare media being presented for all fare payment types. 

4.2.4-13 

Onboard and wayside validators will not explicitly indicate to the customer when they are operating in offline mode. 

4.2.4-14 

All transactions generated in an offline mode will be sent to the ATP immediately upon restoration of communications. 

4.2.4-15 

Onboard and wayside validators will display maintenance screens for troubleshooting and configuration purposes by 
authorized staff. The method and interface used to perform maintenance functions will be determined during design 
review. 

4.2.4-16 

If a failure is detected that causes the validator to cease functioning or cause transactions to fail, the validator will go out 
of service and provide visual indication of the device status. The detected failure will be recorded as an event record. 

4.2.4-17 

Prior to powering down, the validator will transmit all recorded event records and perform all necessary steps to retain 
integrity of all stored data. 

4.2.4-18 

Replaced validator devices will automatically be programmed with their new location (e.g. vehicle ID or station location) 
upon installation and their assigned location information updated in the next gen ORCA System Manager. 

Section 4.3 Driver Display Unit 


A Driver Display Unit (DDU) will be provided which will interface with the onboard validators and display fare validation 
results to the bus operator. The DDU will be connected to the onboard validators, but will not be required for the 


validator to function. 


Fully Conforming 
NonEonforming 








































Capability 

Number 

Capability 

Fully Conforming 

NonBonforming 

Comments 

4.3.1-2 

The DDU will be as simple and compact as possible, as determined during system design and testing, while providing the 
functionality in this section. 

X 



4.3.1-3 

Communications utilized in the exchange of data between the DDU, the onboard validator, and other onboard systems 
will be fully documented and the property of the Agencies. 

X 



4.3.1-4 

The DDU electrical capabilities will conform to the common design requirements presented in Section 3.1. 

X 



4.3.1-5 

Final DDU specifications and performance capabilities will presented for Agency review and approval during design 
reviews. 

X 



4.3.1-6 

The Program needs the SI to work with Agency staff to install all mounting brackets, special hardware, electrical and 
communication wiring and service loops, and terminations/connections required for the installation of the DDU 
equipment. 

X 



4.3.2-1 

The DDU enclosure and components will be made of material suitable to the service under the full range of the specified 
bus environmental and operating conditions. 

X 



4.3.2-2 

DDU housing will be resistant to corrosion, abrasion, scratching, impacts, and vandalism, and withstand standard bus 
cleaning materials. DDU housing color and finish will be such that it minimizes reflection and is highly resistant to fading, 
cracking, and peeling. The device will follow all common design capabilities. 

X 



4.3.2-3 

The DDU will include a physical or virtual keypad that supports driver login using a numeric ID and password as well as 
work assignment. The bus operator will be able to present an employee ID card to the onboard validator to initiate a 
login. 

X 



4.3.2-4 

The DDU will include at least four physical buttons or virtual keypad selections to perform future functions, if needed 
and as determined during system design. 

X 



4.3.2-5 

There will be a "failure" operator key on the DDU to tally events when the onboard validator does not function. 

X 



4.3.2-6 

All required DDU mounting hardware and brackets for each bus type will be provided by the SI. 

X 



4.3.2-7 

The DDU will be installed in a position to allow bus operators to observe fare transactions without interfering with other 
bus controls or indicators. The DDU will in no way obstruct the bus operator's view. 

X 



4.3.2-8 

The DDU will be designed and mounted so that it can be quickly adjusted by the bus operator for optimal viewing angle. 
After adjusting, the mounting hardware will not allow the DDU to shake or become loose as a result of shock and 
vibration encountered during normal bus operation. 

X 



4.3.3-1 

The DDU will receive 12 or 24 VDC power through a circuit breaker assigned specifically to the DDU. External converters 
or power conditioners may be used with Agency approval. 

X 



4.3.3-2 

The DDU will not be adversely affected by other onboard systems being turned on and turned off, including the starting 
of the transit vehicles engine. 

X 



4.3.3-3 

When bus power is turned off, the DDU will remain powered for a configurable time to allow completion of transmission 
of any and all data files. 

X 



4.3.4-1 

The DDU will be the primary visual interface for the driver and will display information such as route and direction and 
fare payment results transmitted from the onboard validator(s), including but not limited to: 

• Validation results 

• Fare amount charged 

• Fare balance remaining 

• Fare product used 

• Passenger type 

• Transfer time remaining 

• Low balance warning (threshold to be Agency configurable) 

• Time-based pass expiration warning (threshold to be configurable) 

• Card/account status (e.g., blocked and reason) 

The operator may be shown additional fare payment details that are not shown to the customer. 

X 


























Capability 

Number 




Capability 


The DDU will serve as an input device for the bus operator to perform system login and set parameters such as route 
number and direction, if that data is not automatically received from other onboard systems._ 


The DDU will allow the driver to tally operational data such as customers with bicycles or wheelchairs, and when a cash 
fare or fare upgrade is paid._ 


The DDU will control the onboard validators including volume control, display brightness, and placing units out-of- 
service, using the Sl-provided System Management API. 


The information displayed on the DDU will be Agency-configurable and may be different from the information displayed 
on the onboard validator. 


When the DDU is replaced the newly installed DDU will automatically be programmed with its new location and have 
their assigned location automatically updated in the next gen ORCA System Manager. 


Section 4.4 Customer Service Terminals 


The CST will be modular devices, and will support multiple configurations, depending on Agency use and purpose. The 
hardware will be optimized for its intended use and configuration. 


All CST configurations and peripheral modules will be subject to Agency review and approval. 


To accommodate the required variety of installation locations, the CST will be compact and easily positioned for user 
comfort as demonstrated during svstem design and testing. 


CST will be designed to permit rapid exchange of the device and peripheral modules to restore service in minimal time as 
demonstrated during system design and testing. Repairs will be performed in the field and no special tools or 
instruments will be required for exchange of modules. 


CST peripherals will communicate over a wireless interface wherever possible. 


For any of the SI supplied CST configuration(s) the same Sl-supplied application and OEM software will be utilized. 


The CSTs installed in Customer Service Offices (CSOs) will provide all functions available. Device modules and key 
functions may include: 

• Computer 

• Keyboard and pointing device 

• Closed-loop media processing 

• Secure cash storage 

• Bankcard processing 

• Customer display 

• Receipt printing 

• Image capture 

• Document scanning 

• EU fare media printing/encoding 

• Uninterruptible power supply 

• Communications interfaces as necessary 


Fully Conforming 
NonEonforming 


































Capability 

Number 



Capability 


The CST used for customer outreach and special events will support remote sales and card personalization programs at 
senior centers, social service organizations, special events and other locations where remote fare media issuance and 
customer account support services are needed. Device modules and key functions may include: 

• Computer 

• Closed-loop media processing 

• Bank card processing 

• Receipt printing 

• Image capture 

• Document capture 

• EU fare media printer/encoder (does not need to support bulk printing) 

• Uninterruptible power supply 

• Communications interfaces as necessary 

The CST will rely on local power and will connect to the next gen ORCA back office via Agency-supplied network 


The CST will conduct a variety of functions. At a minimum, these functions include: 

• Sell all supported fare media, including Legacy ORCA media (and create new transit accounts) 

• Sell all supported fare products (e.g., stored value and passes) and load fare products to transit accounts 

• Sell products such as belt buckles and other non-next gen ORCA fare media and properly record these sales as non- 
next gen ORCA 

• Sell serialized taxi scrip to qualified customers 

• Sell serialized Human Services fare products to authorized Human Services representatives 

• Sell serialized paper tickets individually or in bulk 

• Query transit account status (e.g., passenger type, active/inactive, blocked/unblocked) 

• Query fare payment transaction history 

• Query sales transaction history 

• Query adjustment transaction history 

• Enable fare product for autoload (requires funding source in customer account) 

• Generation of fare payment reversal (e.g., cancellation) 

• Generation of sales reversal (e.g., refund) 

• Generation of an transit account adjustment (e.g., credit or debit) 

• Transfer of balance between two transit accounts 

• Block/unblock card, transit account, or individual fare product 

• Lost, stolen, or damaged card replacement (e.g., associate new card with existing transit account) 

• Make comments on customer accounts and transit accounts 

• Generation of an opt-out refund (e.g., close transit account and issue refund) 

• Create new customer account 

• Query customer account status/data 

• Modify customer account data 

• Register (e.g., associate) a transit account to a customer account 

• Unregister (e.g., disassociate) a transit account from a customer account 

• Add, update or remove a funding source to/from a customer account 

• Close or suspend a customer account 

• Encoding, printing, and issuance of personalized EU fare media (when configured to do so), including the addition of a 
photo 


Fully Conforming 
NonEonforming 
















Capability 

Number 

Capability 

Fully Conforming 

NonBonforming 

Comments 

4.4.1-10 

The CST will support manual entry and validation of ADA paratransit customer data using a simple graphical user 
interface. 

X 



4.4.1-11 

The CST will enable the CSR to print packing slips and mailing labels. 

X 



4.4.1-12 

The CST will allow for every non-next gen ORCA item to be configured with applicable sales taxes. The tax rates will be 
Agency configurable and be established by sales location. 

X 



4.4.1-13 

The CST will support blind reconciliation whereby the user enters at the end-of-shift enters the amount in sales by 
payment method into the CST. The CST will indicate if the totals entered reconcile with the System information and 
allow the user to correct the amount up to an Agency configurable amount of times. Supervisory role logon will allow for 
override of the blind reconciliation feature. 

X 



4.4.1-14 

All CST equipment will comply with the applicable hardware and software capabilities contained in this scope of work. 

X 



4.4.1-15 

The CST will be able to read and endorse checks. The check read/endorse feature may be accomplished through the 
printer or other Agency approved solution. 

X 



4.4.1-16 

All CST equipment will comply with the applicable accessibility and ADA requirements contained in this scope of work. 

X 



4.4.2.1-1 

The CST will include an integrated flat panel touchscreen display with no less than 1080p resolution. 

X 



4.4.2.1-2 

The touchscreen will provide suitable touch sensitivity and resolution to satisfy operator selection and input capabilities. 

X 



4.4.2.1-3 

The CST will support the use of an external display. 

X 



4.4.2.1-4 

The CST will include integrated Ethernet and Wi-Fi (802.11a/b/g/n) to satisfy the capabilities of the configuration. 

X 



4.4.2.1-5 

The CST will access the CRM application through open APIs over the internet. 


X 

Due to the various HW that the CST software needs to interface with (printer, scanner, camera, 
payment terminal, card reader, card printer etc.), a native application is necessary. It is however 
possible to access the SalesForce CRM with a web browser 

4.4.2.1-6 

Any required peripheral modules will be able to be attached to any CST. 

X 



4.4.2.2-1 

The CST will allow for a separate. Agency supplied, full-sized keyboard and a mouse with scrolling wheel to be used if 
deemed necessary by the Agencies. 

X 



4.4.2.2-2 

The CST will include an integrated keyboard and pointing device. 

X 



4.4.2.3-1 

The closed-loop media processing module will be a separate module cabled to the CST. In addition to the separate 
module there may also me an integrated module. 

X 



4.4.2.3-2 

The CST will support the capability to interface with two (2) separate closed-loop media processing modules, one (1) 
each for the customer and the clerk. 

X 



4.4.2.4-1 

The cash storage facility will open only under command of the CST, which will monitor the status of the drawer at all 
times. Cash storage facility installations will be subject to each Agency's approval. 

X 



4.4.2.5-1 

The CST will be PCI- and EMV-certified and compliant with other required banking standards for the acceptance of bank- 
issued credit and debit cards using all common formats based on the latest version of the standard at the time of Final 
System Acceptance. 

X 



4.4.2.5-2 

The bank card processing module will be an integrated or mobile friendly module. 

X 



4.4.2.5-3 

The merchant acquirer approved bank card processing module will include: 

• Magnetic stripe reading 

• Contactless bank card reading 

• Contact (or chip) bank card reading 

• Personal Identification Number (PIN) pad. 

The Personal Identification Number (PIN) pad must meet or exceed all applicable accessibility and ADA requirements, as 
well as meet applicable PCI DSS (version 3.2 or current at the time of deployment) and any other relevant security 
controls included in the ISMS control baseline referenced in Section 3.1.14. 

X 






























Capability 

Number 

Capability 

Fully Conforming 

NonBonforming 

Comments 

4.4.2.5-4 

The contactless bank card validator will read and support all open payment contactless standards, including but not 
limited to: 

• Apple Pay 

• Android Pay 

• Samsung Pay 

• VISA payWave® 

• MasterCard PayPass® 

• American Express ExpressPay® 

• Discover Zip® 

• Contactless EMV 

X 



4.4.2.5-5 

The bank card processing module will employ merchant acquirer approved software and PIN encryption as required in 
accordance with banking capabilities. The Program needs the SI to supply bank card processing modules with production 
encryption keys injected in a secure, PCI-compliant manner. 

X 



4.4.2.6-1 

The CST will be able to print on a single roll of continuous thermal paper or Agency approved alternative. 

X 



4.4.2.6-2 

The receipt printer will provide for easy loading of a new receipt stock as demonstrated during system design and 
testing. 

X 



4.4.2.6-3 

The receipt printer will have a cutting edge to enable the operator to manually separate the receipt from the receipt 
stock. 

X 



4.4.2.7-1 

The CST will have the capability to convey information to customers such as transaction price, status, Pll, and other 
pertinent information. What and how the information gets displayed to the customer will be finalized during design 
review. 

X 



4.4.2.8-1 

When configured to issue personalized fare media, the CST will support the capturing of customer photos. 

X 



4.4.2.8-2 

The image capture device will include both a separate camera and an integrated camera. 

X 



4.4.2.8-3 

The image capture device will include a built-in flash and an image sensor of no less than 10 megapixels. The image 
capture device will produce images of suitable resolution, clarity, and contrast to satisfy the capabilities of photo ID 
cards. 

X 



4.4.2.8-4 

If a separate image capture module is required the SI will provide a means for securing the module for optimized image 
capture. 

X 



4.4.2.9-1 

When configured to issue personalized fare media, the CST will include a means for digitizing customer eligibility 
documents. 

X 



4.4.2.9-2 

Digitizing will support the capture of black & white and color images at a resolution of at least 1200 x 1200 dpi. 

X 



4.4.2.9-3 

Digitizing will support the auto-feeding of documents and support double-side digitizing at no less than 10 pages per 
minute. 

X 



4.4.2.10-1 

The Extended Use (EU) fare media printer/encoder module for use in the CSO and mail center will utilize re-transfer, or 
modern equivalent, printing technology, and will encode EU fare media with requisite data in coordination with the 
printing process. 

X 



4.4.2.10-2 

The EU fare media printer/encoder module for use in the CSO and mail center will print edge-to-edge (e.g., "full bleed") 
in at least four (4) colors (YMCK), and will apply the printed images to a laminate film and then apply the laminate to 
both sides of the card. 


X 

The proposed EU card printers for the CSO & mail center print edge-to-edge, but the requested 
smaller customer outreach printer does not print edge-to-edge 

4.4.2.10-3 

The EU fare media printer/encoder module for use in the CSO and mail center will employ easily replaceable 
consumables for printing and lamination films as demonstrated during system design and testing. 

X 



4.4.2.10-4 

The EU fare media printer/encoder module will provide print resolution no less than 300 dots per inch. 

X 



4.4.2.10-5 

The EU fare media printer/encoder module will produce at least 75 cards per hour as approved in design. 

X 



4.4.2.10-6 

The EU fare media printer/encoder module for use in the CSO and mail center will include input and output card 
hoppers with a capacity of no less than 250 cards each, which will be lockable for security. 


X 

Please refer to Tab 1 - Technical Proposal of INIT's Account Based Open Architecture System 
document for an explaination why we are offering different printers for your different use cases. 
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Capability 


Upon successful printing and encoding, the EU fare media printer/encoder module will inform the CST of the successful 
issuance of each card, and the identification number of each issued card._ 


The CST will communicate with the next gen ORCA back office via secure. Agency-provided, network connection to send 
and receive transaction information, event and status information, clock synchronization information, positive/negative 
lists, and configuration parameters._ 


The CST will be connected to the secure network via an Ethernet port or wireless (Wi-Fi) connection. 


For all transactions requiring back office access to a transit account, or establishing a new transit account, the CST will 
communicate with the back office in real-time using the Sl-provided API. 


If the CST has missed scheduled communications with the back office, upon restoration of communications, the CST will 
automatically initiate communications without interrupting operations._ 


Each CST will receive power from a dedicated Uninterruptible Power Supply (UPS) with sufficient battery capacity to 
operate the CST and all oerioherals for a minimum of 10 minutes. 


The UPS will allow the CST to perform a controlled shut down without any loss of data whenever the UPS determines 
that there has been a loss of primary power. 


The UPS will provide no less than 500 joules of overvoltage (surge) protection for all connected devices. 


Once installed, the CST will not enter service until it has communicated with the back office to receive application 
software, administrative and maintenance logins, risk mitigation lists, and other configuration data. 


Authorized users will be able to remotely monitor and manage the CST using the System Manager. Remote management 
functions will include: 

• Changing configuration parameters 

• Enabling and disabling payment methods 

• Synchronizing date and time 


On each CST the Program needs the SI to supply, install, and configure client versions of anti-virus and anti-malware 
software. 


The Program needs the SI to submit descriptions of the CST software design for Agency review and approval. CST 
software design deliverables will include: 

• Data registers 

• Transaction, event, login, etc. records 

• Operator interface 

• Configuration parameters and their value range 

• Risk mitigation list storage, update, and processing (if applicable) 

• Transaction limitation procedures 

• Setup and administration procedures 

• Login types and permitted functions 

• Anti-virus and anti-malware software and procedures 


The CST will generate transactions and events, including operator login and logout and diagnostics. Each data record will 
incorporate a unique identification number for that CST and day, and will be date/time stamped._ 
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Each CST customer transaction record will consist of the following, at minimum: 

• Date and time 

• Device ID 

• Location ID 

• Operator (e.g., clerk) ID 

• Card number 

• Transit account 

• Transaction type (e.g., card sale, value load, account inquiry, refunds) 

• Cards sold (where applicable) 

• Stored value or fare products loaded (where applicable) 

• Passenger type (e.g., adult full fare, youth, senior, disabled) 

• Transaction value (where applicable) 

• Payment type and amount 

• Transaction result (e.g., success, failure) 

• Transaction ID 

Transaction records details will be finalized during design review. 


When a user signs on to the CST, the following data will be stored in a data record: 

• Date and time 

• Device ID 

• Location ID 

• Operator ID 

• Login attempts 

When the user logs off the CST, the device will store a similar record. 


The CST will be capable of detecting basic internal malfunctions and will display failures directly on the operator display 
and alert the System Manager. The malfunction detection will cover at least failure of power or control circuitry, and any 
failure of the closed-loop media processing module that could result in a false, incomplete, or corrupted encoding of a 
smart card. 


The CST will be capable of recording data locally representing no less than 1,000 events, including changes in status, 
communication problems, and problems detected during the automatic diagnostic testing. At a minimum, each event 
record will include: 

• Date and time 

• Device ID 

• Event code 

• Any associated event data 

• Identifier of the failed test 

• Iteration number of test 

• Reason for test failure (unique code) 

• Additional information to define the nature of the failure 


Each CST will contain audit registers that track the following information at a minimum: 

• The total count and value of all transactions completed by the CST since data was last uploaded to the back office. 

• The date and time of the last successful data upload to the back office. 

These registers will be modified only by the CST itself and will not be manually alterable. 



-.3.2-6 


X 
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CST audit register records will be transmitted to the back office at the end of service day for reconciliation, or upon a 
configurable time period. 


When required, modification of the CST application software and any OEM application or operating system software will 
be performed by downloading new software from the back office. The back office database will record and track the 
version number of all such software in each CST, and the date that the software versions were downloaded and 
installed. 


Each time the CST communicates with the back office, the back office will transmit any updates to the CST application 
software. The CST will not commence updating its software until it has received and verified the complete software 
delivery. 


Upon receipt and verification of the software update, the CST will apply the update (rebooting if necessary) at a time 
configurable by the Agencies for each CST. 


Operating parameters will be downloadable to the CST from the back office via the wide area network provided by 
Agency, as appropriate for each installation or CST configuration._ 


The CST design will support Agency configurability through numerous adjustable parameters. The CST application 
software will at minimum support Agency configuration for: 

• Value of deposit to be collected for new or replaced fare media 

• Fare products and non-next gen ORCA products available for sale and upgrade 

• Payment method selection 

• Receipt content 

• All text and touchscreen labels 

• Authorized users and passwords (if stored locally at the CST) 


Upon issuance and/or initialization of a smart card, the CST will record in the back office an issue record, including the 
date, time, fare category, card identification number, and other pertinent information of the smart card and any 
associated transit account. 


The Fare Media Management application (FMM) will track the smart cards distributed to each Agency sales location. 
Using the list of fare media issued to each sales location and the issuance and/or initialization records previously 
transmitted to the back office, it will be possible for authorized users to query the FMM for the identification numbers 
and total quantity of smart media that remain in each sales location's inventory. 


The CST will remain inactive and unable to perform any functions unless a proper login has been completed. 


When configured with a cash storage facility the CST will require the operator to identify the cash balance at the start of 
each shift. The starting balance will be Agency configurable. 


The CST will support relief shifts, with the replacement of the cash storage facility. The CST will also maintain statistics for 
the relief shift separately and will not affect the main shift information. 


If the CST has not been used in a number of minutes configurable by Agency, the user will be automatically logged out. 



Upon end-of-shift condition, the CST will produce an end of shift report and receipt depicting at a minimum the ending 
balance of the cash storage facility, summary of transactions, payment methods used, quantity of products sold, 
reversals, refunds. The report will be approved during design. 


The CST will store a data record for each successful login, each unsuccessful login, and each logout. 


The CST will be configurable to use a multi-factor login authentication mechanism that observes the guidelines provided 
in NIST 800-63, and approved by the ORCA CISO. The CST will support more than one method for additional factors of 
the authentication process and those methods will be approved during design, always observing applicable industry best 
practices (such NIST 800-63). 


The CST will allow the CSR to login using a properly configured smart card. Smart card login will be one factor of multi¬ 
factor login authentication. 
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The CST will function as an intelligent cash register, allowing customers and CSRs to interact in a manner as similar as 
possible to normal retail sales transactions. Sales transactions will include, but are not limited to: 

• Purchase of new fare media 

• Adding of value and products to existing transit accounts 

• Purchase of non-next gen ORCA products 


When issuing a new EU fare media, the CST will permit the clerk to override the default. Agency-configurable card fee. 


The purchase of multiple cards and multiple products, including products that are other than next gen ORCA fare 
products, will be able to be performed in a single transaction, with payment collected once. 


When configured to conduct sales, the CST will support a variety of funding methods, including: 

• Cash 

• Checks 

• Agency and third-party issued vouchers 

• Bank cards (credit and debit) 

• Mobile wallets 

• Any combination of the above 

The CST will also support the payment, or partial payment, for the purchase of a pass or multi-ride product using stored 
value in same transit account where the pass or multi-ride product is being loaded. 


The CST will support split payments where up to three (3) funding methods can be used, including multiple bank cards, 
to complete payment for a single sale. 


For each sales transaction, the CST will enable the clerk to select the payment method. If the clerk selects more than one 
(1) payment method, the CST will prompt the clerk to enter the amount to be paid using each payment method. 


Cash transactions will provide the total amount due, allow the clerk to enter amount tendered, and display the change 
due. 


The CST will control and monitor the cash storage facility, and open the cash storage facility upon calculation and display 
of the amount of change due. 


The CST will provide an option to either print, text, or email a customer receipt for every completed sales transaction. 
Receipts will include the resulting status and value of the customer's transit account, where applicable. 


For each completed transaction, a sales transaction will be stored and transmitted to the System back office using Sl- 
provided Fare Distribution API. 


The CST will enable a clerk to display and print totals of all completed transactions by that clerk for the current day. 


The CST will enable an administrative user to display and print totals of all conducted transactions for the current and 
each of the prior seven (7) davs. These totals will indicate dailv totals bv clerk and oavment tvoe. 


When configured to do so, the CST will include the necessary software and peripherals to enable Agencies to issue 
personalized fare media. 


Personalized fare media may include the customer's name and photograph printed on one side of the card, 
accompanied by other Agency-defined graphics and information. 


Using the appropriate customized printing template, the CST will print and issue personalized fare media. 


The SI shall supply printing templates (also known as "masks") using Agency-supplied graphic designs for all personalized 
fare media. The CST will support no fewer than 25 pre-loaded templates from which the user will select. Where possible, 
template selection will be automatic based on fare media. 
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The CST will support the ability for a participating customer account to add a company logo to the card template(s). 


When printing a personalized fare media, the CST will scale and crop the photo image to fit within the area defined by 
the printing template without distorting the image or changing its native aspect ratio._ 


The CST will support issuance of personalized fare media in individual and bulk production modes. 


For fare media personalization, a digital camera controlled by the CST will capture the customer images as necessary. 


All CSTs will support production runs (using data imported from the CRM or an external source) for bulk fare media 
personalization in quantities of one (1) to at least 250 cards per batch_ 


For bulk fare media personalization production runs, the CST will use data files imported in a Sl-specified format. The 
data files will include the customer name, digital photograph, and other information as required. 


The CST will support the capture of all data needed to validate, register, and issue personalized fare media for reduced 
fare and paratransit customers. 


The CST will support manual entry of reduced fare transit account registration data using a simple graphical user 
interface. 


The CST will capture reduced fare applications and supporting documentation using the Sl-provided document scanner. 


The CST will capture reduced fare customer photographs using the Sl-provided camera. 


All customer data captured and used by the CST will be securely stored within the CRM using the Sl-provided API and will 
not be permanently stored locally on the CST. 


The CST will allow the CSR to override the card printing process. Card printing override functionality will be further 
defined during design review._ 


Whenever fare media is presented to the CST closed-loop media processing module, the CST will read the fare media 
and query the back office using the Systems Integrator-provided Transit Account Management API to display the current 
status and value of the associated transit account on the operator display and customer display if one exists in current 
CST configuration. 


If the customer's smart card is not functioning, the CST will permit the clerk to manually enter the card identification 
number. 


Upon request, the CST will query the back office for details of the most recent transactions posted to the transit account. 
Upon receipt of the transaction history, the CST will display the results on the operator display._ 


The number of prior transactions to display when viewing a transit account in the CRM application will be Agency- 
configurable._ 


For each prior transaction displayed by the CRM, history details will include, at minimum: 

• Date and time of transaction 

• Generating device/system (e.g., VM, retail location, autoload) 

• Transaction type (e.g., sales transaction, stored value usage, pass usage, adjustment) 

• Transaction value 

• Payment method 

• Transaction location (e.g., station name, bus route) 


Upon request, the CST will print a receipt of the current status, transit account value, transaction history, and current 
and past transaction receipts. 


The CST will enable operators to setup and modify customer accounts using the Systems Integrator-provided Customer 
Account Management API._ 



The printer input hopper has space for 200 cards. 
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Number 







The CST will enable the operator to, at a minimum: 

• Create a new customer account 

• Register an anonymous transit account 

• Associate a transit account with multiple customer accounts 

• Disassociate a transit account from a customer account 

• Query and edit program registration details 


The CST will enable the operator to modify any fields in the existing customer accounts that are deemed user-alterable. 


The CST will enable operators to establish, modify, and cancel customer subscriptions for autoload, including the 
addition and modification of funding sources. 


Some reduced fare privileges are subject to expiration. The CST will include a function to re-authorize reduced fare 
privileges and update the customer's transit account information with a new reduced fare privilege expiration date. 


The CST will support replacing registered EU fare media by disassociating/ deactivating the lost or stolen fare media from 
the transit account and associating/activating new fare media in its place. Disassociating the lost or stolen fare media will 
not prohibit the customer or designated Agency personnel from accessing transaction history associated with that card. 


Prior to replacing registered EU fare media, customer identity will be verified using information accessible via the CST 
and in accordance with the applicable securitv controls established in the ISMS control baseline. 


If the replacement fare media requires no personalization, the CST will prompt the operator to present the new fare 
media to the closed-loop media processing module. 


When replacing a previously issued personalized fare media, the CST will support use of the digital photograph, printing 
template, and other data from the original issue record to facilitate replacement without requiring the customer's 
presence, or the use of the digital camera to create and store a new digital image. 


Upon reading or issuing the replacement fare media, the CST will transmit to the back office an issue record containing 
the card's identification number, and a corresponding record to block use of the lost card._ 


Replacing a malfunctioning smart card will be possible. Procedures to replace a defective smart card will be similar to 
those used to replace lost registered fare media, but replacement of a defective card will not require the fare media to 
be registered. The replacement process will support manual entry of the defective smart card's identification number as 
the means to initiate replacement. 


CST operators with appropriate access rights will be able to initiate transit account adjustments by reversing prior sales 
or fare payment transactions, or directly adding or removing stored value or products. 


CST operators with appropriate access rights will be able to initiate an opt-out refund that results in the closing of a 
transit account associated with a customer account and issuance of a cash or check refund to the customer. The System 
will support the charging of a refund fee that is Agencv configurable. 


CST operators with appropriate access rights will be able to add fare products to a transit account on a goodwill basis 
resulting in no cost to the customer._ 


The CST will fully record and immediately transmit to the back office all adjustment and reversal transactions. 


Section 4.5 Vending Machines 


The vending machine (VM) will be designed as a simple, low-maintenance, and low-complexity machine in a cost-saving 
design that provides the functionalitv specified herein and the common design capabilities. 









































Capability 

Number 


Capability 


The VM will be designed to accommodate first-time or occasional users, as well as regular customers who need to reload 
their transit accounts. At a minimum, these functions will be supported: 

• Purchase one or more new smart cards (associated with a new transit account) with and without value 

• Load stored value or fare product(s) to an existing transit account 

• Review transit account balance and history 

• Accept U.S. coins and bills (Agency configurable should some Agencies choose to not accept cash) 

• Accept authorized magnetic strip, contact, and contactless bank cards 

• Inserted cash will be held in escrow and returned to the customer should the transaction not be completed for any 





• Display instructions and notices 

• Provide audio output of messages and instructions 

• Contain required security and alarm system 

• Communicate over a network to send and receive transaction data in real-time 

• A full list of transactions and detailed process flows will be determined during design reviews. 


The VM will be modular and have the capability to replace, activate, or deactivate the hardware components 
individually. The modules and components will be easily serviced. 


If a component or function is enabled/disabled, the VM will automatically adjust its display, operation, and maintenance 
status according to the active components._ 


The VM will be able to accept credit and debit cards and cash/coin for payment. 


The VM will detect when the bill vault is near-full (%) and full (%), and record and transmit an event record. The 
determination of a nearly full condition will be adjustable bv the Agencies for each VM. 


The VM will detect when the coin vault is near-full (%) and full (%), and record and transmit an event record. The 
determination of a nearly full condition will be adjustable by the Agencies for each VM._ 


The Light Feature Vending Machine (LFVM) will be a simple, low-cost, low-complexity machine that allows first-time and 
regular customers to purchase and reload EU fare media. The LFVM is expected to reduce the capital costs, maintenance 
activities, and customer complexity associated with traditional full feature transit VMs. To this end, the LFVM will not 
issue change. The device will provide Agencies with the flexibility to enable and disable features or components of the 
LFVM. 


The LFVM will not issue change. Any change due to a customer for fare product loads to Extended Use (EU) fare media at 
an LFVM will be returned (e.g., loaded) as stored value to the same transit account within the same transaction. 


All VM equipment will comply the applicable hardware and software security capabilities contained in this scope of 
work. 


All VM equipment will comply with the applicable accessibility and ADA requirements contained in this scope of work. 


All VM equipment will comply applicable PCI/PI I requirements contained in this scope of work. 


The VM enclosures will be rugged and function under harsh environmental conditions including: direct sunlight, 
moisture, dust/grit/sand, humidity, electrical storms, exposure to urban and marine environment, and the range of 
elevations and altitudes in the operating region. 


The design of the VM mounting system will be vandal-resistant and will include robust anchoring that prevents the VM 
from being dislodged._ 


The VM cabinets will be constructed from stainless steel without any visible fasteners. The enclosure finish and corners 
will be rounded to avoid sharp edges, corners, or protrusions that may cause injury to customers. 


The VM enclosures will be resistant to corrosion, abrasion, scratching, impacts, and vandalism, and withstand standard 
cleaning materials. Color and finish will be such that it minimizes reflection and is highly resistant to fading, cracking, and 
eeling. 


Fully Conforming 
NonEonforming 
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Number 








Capability 


The design of the VM enclosure will permit installation as stand-alone units, side-by-side units, back-to-back units, and in 
recessed areas. 


The VM cabinets will be constructed to provide the highest protection against vandalism and burglary. Reinforcement 
will be provided at the locations (screen, doors, access ports, etc.) where there is a higher possibility of vandalism. All 
doors and other access points will be designed to inhibit the use of prying tools to gain access to the interior of the 
machine. 


The VM mounting pedestal and any external features (such as button panels, rain shields, and light fixtures) will be 
weatherized, robust, and vandal-resistant. 


While all outer doors are secured, the VM will remain operational and undamaged after experiencing any impact 
resulting in a concentrated load of 400 pounds per one (1) square inch on any part of the enclosure. 


The VM cabinet and mounting hardware will accommodate variations in station and sidewalk construction. Mounting 
pedestals will be sized according to need, and specifics will be provided by the Agencies during design review. 


The VM cabinet will provide controlled levels of access to the interior of the equipment for maintenance personnel, 
revenue servicing personnel, and cash processing personnel, as defined by the Agencies. Locks must be secured locks, 
rogrammable to more than one key. 


As necessary, blanking plates will be provided for installation over any outer door openings of the VMs resulting from the 
removal of an external component or module. All such blanking plates will be easily secured, and will provide security 
against intrusion and vandalism. 


The VM enclosure and pedestal design will be submitted to the Agencies for review and approval. 


The LFVM will have a footprint that is approximately half the size of a full-feature VM. 


The VM cabinets or pedestal will be capable of housing a network switch to enable all devices in one area to be 
connected through a single connection to the station communications room, and limit the number of Ethernet runs 
required to each installation location. 


The VM display screen will consist of a color, transflective backlit flat panel capacitive touchscreen display that is clearly 
viewable in davtime and night-time conditions. 


The VM customer display screen will measure at least 10 inches diagonally. 


The display screen will provide resolution of no less than 1024 by 768 pixels, and at least 65,000 colors (RGB 16 bit) per 
pixel. 


The VM display will produce a minimum of 1,000 nits brightness with at least a 750:1 contrast ratio, and provide a level 
of visibility sufficient to allow all displayed instructions to be read easily by the customer under all ambient light 
conditions and without the need for anv additional oermheral light source or shading device. 


The visibility and usability of the VM display will be unaffected by precipitation, temperature, sunlight, and other 
environmental conditions typical of the operating region._ 


The VM display will be protected to be resistant to scratches and other normal wear. Coatings or other materials applied 
to the outer surface of the display's protective shield will withstand normal customer use, industry standard station 
cleaning materials, and be easily replaced if necessary. 


The display screen will be easily replaceable from within the VM interior, and require minimal maintenance effort. 


All portions of the display screen will be visible and not obstructed by any portion of the VM door, mounting bezels, or 
other external elements. 


The display screen will be installed close enough to the VM surface to avoid any parallax effect, or the apparent shift of 
screen objects relative to customer touches or button placement. 


The visibility and usability of the VM display will be unaffected by precipitation, temperature, sunlight, and other 
environmental conditions typical of Puget Sound operating region. 


The VM Bill Handling Unit (BHU) will accept paper currency, and include a bill validator, escrow module, and bill vault. 




























































Capability 

Number 

Capability 

4.5.2.3-2 

The bill validator will be capable of accepting all U.S. Treasury variations of $1, $2, $5, $10, $20, $50, and $100 bills in 
circulation at the time of Final System Acceptance. 

4.5.2.3-3 

As the U.S. Treasury releases new designs of bills, the bill validator will be capable of being programmed to accept the 
new designs while continuing to accept the current designs. 

4.5.2.3-4 

The bill validator will be equipped with a protective shutter to guard against foreign matter so that it does not enter the 
BHU while the machine is not accepting bills. 

4.5.2.3-5 

The bill validator will remain closed until a transaction is selected for which cash payments are available. The shutter will 
automatically open once the payment due has been displayed. 

4.5.2.3-6 

The bill validator will be able to accept bills inserted in any of the four possible length-wise orientations. 

4.5.2.3-7 

The bill validator will accept one bill at a time and will determine the denomination and validity of the currency. 

4.5.2.3-8 

The bill validator will determine the denomination and validity of both sides of a document by dimension checks and 
pattern and color recognition. 

B 

The bill validator will meet the following acceptance rates: 

• At least 98% of valid bills are accepted upon initial insertion. 

• At least 99% of valid bills are accepted in no more than two insertion attempts. 

4.5.2.3-10 

The bill validator will identify valid acceptable bills with at least 99.999% accuracy. 

4.5.2.3-11 

The bill acceptor may reject bills with excessive physical defects. 

4.5.2.3-12 

The bill validator will be able to detect counterfeit bills, including copies made in either single or double-sided printing 
on an electronic copier and those made with color printers. 

4.5.2.3-13 

If the bill validator deems the inserted document to be invalid, the document will be returned and gripped so that the 

VM retains a hold on the item. 

4.5.2.3-14 

The bill validator will be designed to reject or expel pieces of paper or other foreign material that can be introduced into 
the bill insertion slot. 

4.5.2.3-15 

The bill validator will be secured via a high-security lock and will be separately removable for servicing. 

4.5.2.3-16 

Upon acceptance of each inserted bill, the bill validator will forward the bill to an escrow to be stored temporarily until 
completion or cancellation of the transaction. 

4.5.2.3-17 

The bill escrow module will have the capacity to store a minimum of 10 bills. 

4.5.2.3-18 

When the bill escrow is full, or a configurable limit of inserted bills per transaction is reached, the bill validator will cease 
accepting bills. 

4.5.2.3-19 

If the customer cancels the transaction or the VM aborts the transaction, the BHU will return from escrow the bills 
inserted for the transaction. 

4.5.2.3-20 

When a transaction is completed, all bills in the bill escrow module will be transported to the bill vault for retention. 

Using sensors or other means, the machine will confirm the passage of all bills to the bill vault; failure to detect a bill 
being deposited into the bill vault will be considered a jam and the machine will cease accepting bills and display an 
appropriate message to customers. 

4.5.2.3-21 

The BHU will be equipped with a removable bill vault. The bill vault will have a capacity of no less than 500 stacked bills 
in street condition and weigh no more than 50 pounds when full. 

4.5.2.3-22 

The bill vault will be constructed of sturdy and tamper-proof material, and will withstand normal handling and regular 
removal and replacement without deformation that would in any way interfere with the insertion and removal process. 

4.5.2.3-23 

It will not be possible to open the bill vault while installed in the BHU, nor will it be possible to install an open or 
unlocked bill vault into the BHU. When properly installed in the BHU, it will not be possible to access bills in the bill vault 
without damaging the vault in an obvious manner. 

4.5.2.3-24 

The bill vault will remain secure when removed from the VM. Access to the bill vault will be granted only with keys 
available to revenue staff. 


4.5.2.3-24 


Fully Conforming 
NonEonforming 






























































Capability 

Number 

Capability 

Fully Conforming 

NonBonforming 

Comments 

4.5.2.3-25 

The bill vault will have handles placed to avoid injury and provide adequate hand clearance for easy insertion, removal, 
and carrying. 

X 



4.5.2.3-26 

Each bill vault will include a printed and electronically encoded serial number. The serial number will be read by the VM 
for reporting upon bill vault insertion and removal. 

X 



4.5.2.4-1 

VMs will be equipped with a Coin Handling Unit (CHU) including, but not limited to, a coin acceptor/verifier, a coin 
escrow module or coin recyclers, and a coin vault. 

X 



4.5.2.4-2 

The coin acceptor/verifier will accept all variations of U.S. 5-, 10-, and 25-cent and dollar coins in circulation at the time 
of Final System Acceptance. 

X 



4.5.2.4-3 

As the U.S. Treasury releases new designs of coins, the coin acceptor/verifier will be capable of being programmed to 
accept the new designs while continuing to accept the current designs. 

X 



4.5.2.4-4 

The coin acceptor will contain a coin insertion slot that will be sized to limit the dimensions of inserted material to the 
largest coin accepted. To minimize jams, the coin slot will also be sized to prevent the simultaneous insertion of two 
coins. 

X 



4.5.2.4-5 

The coin insertion slot will be equipped with a protective shutter to guard against foreign matter so that it does not 
enter the CHU while the machine is not accepting coins. 

X 



4.5.2.4-6 

The coin insertion slot will remain closed until a transaction is selected for which cash payments are available. The 
shutter will automatically open once the payment due has been displayed. 

X 



4.5.2.4-7 

The geometry of the coin path and other provisions of the coin acceptor will prevent the retrieval of coins by fishing such 
as with wire or attached thread. 

X 



4.5.2.4-8 

The coin acceptor/verifier will determine the denomination and validity of coin types, and identify invalid or counterfeit 
objects ("slugs"). 

X 



4.5.2.4-9 

The coin acceptor/verifier will meet the following acceptance rates: 

• At least 98% of valid coins are accepted upon initial insertion. 

• At least 99% of valid coins are accepted in no more than two insertion attempts. 

All known counterfeit coins, common slugs, foreign coins, and coins of denominations not accepted by the machine are 
rejected upon every insertion. 

X 



4.5.2.4-10 

The coin acceptor/verifier will identify valid acceptable coins with at least 99.99% accuracy. 

X 



4.5.2.4-11 

The coin acceptor/verifier will reject and return to a coin return bin unverified, counterfeit, excessively bent, and foreign 
coins, as well as slugs and other foreign objects. 

X 



4.5.2.4-12 

The coin acceptor/verifier will be key-locked into the machine and will be removable for service and replacement. 

X 



4.5.2.4-13 

Upon acceptance of each inserted coin, the CHU will forward the coin to an escrow to be stored temporarily until 
completion or cancellation of the transaction. 

X 



4.5.2.4-14 

The coin escrow module will have the capacity to store a minimum of 35 coins. 

X 



4.5.2.4-15 

When the coin escrow is full, or a configurable limit of inserted coins per transaction is reached, the CHU will cease 
accepting coins. 

X 



4.5.2.4-16 

If the customer cancels the transaction or the VM aborts the transaction, and the CHU will return from escrow coins 
inserted for the transaction. 

X 



4.5.2.4-17 

When a transaction is completed, all coins in the coin escrow module will be transported to the coin vault or coin 
recirculation module, if present. Using sensors or other means, the machine will confirm the passage of all coins to the 
coin vault; failure to detect a coin being deposited into the coin vault will be considered a jam and the machine will 
cease accepting coins and display an appropriate message to customers. 

X 



4.5.2.4-18 

Each VM will be equipped with a removable coin vault that has a capacity of at least 300 cubic inches and weighs no 
more than 50 pounds when full. 

X 



4.5.2.4-19 

The coin vault will withstand regular removal, replacement and normal handling without deformation or in any way 
interfering with the insertion and removal process. 

X 
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Capability 


It will not be possible to open the coin vault while installed in the machine, nor will it be possible to install an open or 
unlocked coin vault into the machine. When properly installed in the machine, it will not be possible to access coins in 
the coin vault without damaging the vault in an obvious manner. 


The coin vault will be self-locking and self-closing, so that when removed from the machine, it cannot be opened other 
than through an authorized process. Any coin vault will remain secure when removed from the VM. Access to the coin 
vault will be granted onlv bv keys available to revenue staff. 


The coin vault will have a handle or handles placed to avoid injury, which provides adequate hand clearance for easy 
insertion, removal, and carrying. 


Each coin vault will include a printed and electronically encoded serial number. The serial number will be read by the VM 
for reporting upon coin vault insertion and removal. 


The FFVM will be equipped with a coin issuance system to accommodate cash transactions where over payment occurs. 
The coin issuance system will be designed to minimize the need to perform revenue servicing of the machines. 


The FFVM coin issuance system will issue U.S. 5-, 10-, and 25-cent and dollar coins. 


The maximum amount of change available from the FFVM per transaction will be Agency configurable. 


The VM will include a Bank Card Processing Unit (BCPU) to process bank cards (credit and debit) for the funding of fare 
products and media._ 


The VM will be PCI- and EMV-certified for the acceptance of bank-issued credit and debit cards using all common formats 
based on the latest version of the standard at the time of Final System Acceptance. VMs will be capable of re- X 

certification with newer versions of the PCI and EMV standards via software upgrades as necessary. 


The magnetic stripe and contact bank card reader will be combined to accept and process standard size cards with 
ISO/IEC 7811 magnetic data stripes and all EMV-compliant contact (chip and PIN) cards. 


The magnetic stripe/contact bank card reader will consist of a push/pull (insert/remove) card reader such that the bank 
card is not captured completely by the reader. Sensors will detect the insertion and removal of cards from the reader X 
unit. 


The contactless bank card reader will read and support all open payment contactless standards, including but not limited 
to: 

• Apple Pay 

• Android Pay 

• Samsung Pay 

• VISA payWave® 

• MasterCard PayPass® 

• American Express ExpressPay® 

• Discover Zip® 

• Contactless EMV 


The BCPU will include a secure bank card PIN keypad. The PIN pad will be vandal resistant, weather resistant and not be 
removable from outside and be easily replaceable. It will have a life expectancy of 5 million cycles. 


The contactless bank card reader will be separate and apart from the customer facing smart card validator used to 
process load transactions. Both will be clearly identified to avoid confusion._ 


The PIN keypad will employ encryption as required in accordance with banking capabilities. The Program needs the SI to 
supply all PIN keypads with production encryption keys injected in a secure, PCI-compliant manner. 


The PIN keypad will be capable of operating in both an encrypting and non-encrypting or "clear" mode so that it can be 
used for data entry and customer selection by the visually impaired. 















































Capability 

Number 

Capability 

Fully Conforming 

NonBonforming 

Comments 

4.5.2.5-10 

The magnetic stripe/contact bank card reader card slot will be sealed so that no liquids introduced into the slot enter the 
interior of the machine. 


X 

The opening cannot be sealed. The construction and IP classification (IP34) of the reader prevent 
using the slot to pour liquids into the TVM. 

The VM is IP54 with the exception of the credit card reader and the coin and bill acceptor that is IP34. 
There is no credit card reader with IP 54 (since you have to be able to enter a credit card). This is 
industry standard. 

4.5.2.6-1 

The VM will incorporate an internal ISO/IEC 14443 contactless smart card validator/encoder that will be used to encode 
and issue contactless media stored in the VM. This is in addition to the external contactless smart card validator/encoder 
used bv customers to process load transactions. 

X 



4.5.2.6-2 

The EU fare media validator/encoder will be integrated with a media dispensing unit that will issue the EU fare media 
and together comprise a smart card Encoder/Dispenser (SED). 

X 



4.5.2.6-3 

The SED will utilize removable cassettes to store the contactless media stock. The cassettes will securely hold cards and 
enable service staff to replenish or exchanging cassettes quickly and securely. 

X 



4.5.2.6-4 

In total the installed cassettes will have a capacity of no less than 500 cards. 

X 



4.5.2.6-5 

The SED will dispense cards into a media dispense tray or slot no more than three (3) seconds after commencing the 
encode/dispense process. 

X 



4.5.2.6-6 

Prior to dispensing a new card, the SED will confirm that the card is functioning properly. If the SED cannot read the 
Unique Identification Number (UID) or verify the data is encoded correctly, the module will capture the card in a card 
reject bin and attempt to encode/dispense another card. 

X 



4.5.2.6-7 

The VM card reject bin will have a capacity of no less than 10 cards. 

X 



4.5.2.6-8 

If the SED fails to issue the media after a configurable number of attempts (initially set to three [3]), the machine will 
disable the SED module and send a maintenance alert. 

X 



4.5.2.7-1 

The VM will be equipped to print and issue receipts for fare transactions and audit tickets for maintenance activities. 
Receipts will be printed on separate receipt stock using a thermal receipt printer or Agency approved alternative. 

X 



4.5.2.7-2 

The receipt printer will issue receipts and audit tickets from paper-based roll stock that is commercially available in the 
U.S. Receipt stock will follow applicable standards for service and replacement. 

X 



4.5.2.7-3 

The receipt printer will be able to print all alphanumeric characters in both upper and lower case and all ASCII 
characters. Printed characters will be produced with a minimum height of 0.12 inches and a maximum height up to 

1 inch. 

X 



4.5.2.7-4 

The receipt printer will utilize a thermal print head that provide no less than 100 dots per inch of resolution. 

X 



4.5.2.7-5 

Thermal print heads will produce no fewer than 250,000 receipts without misprinted pixels due to wear or electronic 
failure. 

X 



4.5.2.7-6 

The receipt printer will be equipped with a cutting mechanism to cut individual receipts from the roll supply. Each cutter 
will perform at least 1 million cuts without requiring replacement or sharpening. The cutter will be designed such that no 
adjustment of the cutting edges will be required. 

X 



4.5.2.8-1 

In addition to the display and other modules described in this section, several elements on the front of the VM will 
comprise the customer interface including, but not limited to: 

• Contactless smart card validator 

• Physical push buttons 

• Audio interface 

• Headphone jack 

• Media dispense tray/slot 

• Instructional graphics and text 

• Information sign 

Final VM configurations will be determined during design review. 

X 

























Capability 

Number 



Capability 


A customer-facing contactless smart card validator compliant with both Type A and B variants of the ISO/IEC 14443 
standard will be installed in the VM to perform the following functions at minimum: 

• Read contactless media to bring VM out of idle state 

• Load fare products or value 

• Check account balance and history 

The validator will also have write capabilities as per risk mitigation strategies. 





The contactless validator will be separate and apart from the contactless bank card reader that is part of the BCPU. Both 
will be clearly identified to avoid confusion. 


Any push buttons that are provided for customer selection functionality will conform to the following characteristics: 

• Made of stainless steel, hardened aluminum, or other Agency-approved hardened and weather-resistant material 

• Have tactile movement when pressed 

• Be accompanied by an audible tone when pressed 

• Provide appropriate (ADA compliant) resistance when pressed 

• Be protected against vandalism, including impact from customers 

• Be liquid-proof and sealed from outside moisture 

• Not be removable from the outside 

• Meet or exceed all applicable ADA guidelines 


VM instructional graphics and text will be modular and able to be changed to match different VM configurations, if 
applicable. 


The design of instructions and graphics will minimize glare and other effects of sunlight and ambient lighting. 


The VM front panel will include an optional convex "fish eye" mirror, which will enable a customer using the VM to see 
behind them. 


Instructional graphics will include diagrams that clearly depict proper insertion orientation of bills and bank cards into 
their respective slots. 


Conceptual designs of VM instructions and related graphics will be submitted during design review for Agency review 
and approval. 


The VM will incorporate a removable information signage holder in a prominent position to display printed information, 
such as: 

• Fare pricing and information 

• Agency contact information 

• Service announcements 


The VM will include an audio interface and internally mounted vandal-resistant speaker to provide configurable audio 
tones and voice annunciation. 


VM audio volume will be able to be adjusted remotely and by the customer for each machine, and will be audible in all 
station environments. 


The VM will include a media dispense tray or bin that will safely hold dispensed media and receipts. 


The media dispense tray will be recessed and may be covered with a clear polycarbonate spring-loaded or weighted 
door. The dispense tray and its door will be robust, scratch-resistant, visually prominent, and resistant to intrusion from 
the outside. 


The media dispense tray will be designed to drain any liquids that enter. 


Fully Conforming 
NonEonforming 















































Capability 

Number 

Capability 

4.5.2.8-17 

The layout of the keys on the VM PIN keypad will be in compliance with or exceed all applicable accessibility and ADA 
requirements. 

4.5.2.8-18 

The information signage holder will be suitable for use in an outdoor environment, securely mounted, and may 
supplement information on the customer display. 

4.5.2.9-1 

The VM outer door lock will utilize an electronic high-security lock such as Cyber Lock® or Agency-approved equivalent. 

4.5.2.9-2 

The keyways for all high security keys will be registered to the Agencies, and replacements will be available only to 
authorized personnel, or their authorized representative. 

4.5.2.9-3 

Sensors will detect the status of the outer door lock. The VM door will be considered open and unsecure if the outer 
door lock is not in the fully locked position. 

4.5.2.9-4 

All security locks will be designed in such a way that the door cannot remain in a closed and unlocked position. 

4.5.2.10-1 

Each VM will be equipped with an alarm unit that will have the ability to monitor machine security conditions and 
provide alerts to the back office in real-time. If the VM does not have power or is disabled for any reason, the alarm unit 
will continue to operate independently and monitor the machine for security breaches and impacts. 

4.5.2.10-2 

The alarm unit will be disarmed through an authorized entry, and will be triggered by an unauthorized entry. Each time 
an alarm event is detected, the event record with date and time will be stored and transmitted to the back office. 

4.5.2.10-3 

Adjustable sensors will detect direct physical impacts to the VM enclosure, breakage of the customer display, and 
attempts at unauthorized or forced entry. The alarm unit will activate a local siren as soon as the impact sensor is 
triggered. The siren will shut off and re-arm after a configurable time period unless continued impacts or attempts at 
intrusion are detected. 

4.5.2.10-4 

Access to the interior of the VM for maintenance and servicing using an authorized key will disable the alarm while 
service is being performed. If authorized VM access is not followed, the intrusion alarm will be activated and the VM will 
record and transmit a security event. 

4.5.2.10-5 

A security and alarm process for VM access will be submitted for review and approval by the Agencies. 

4.5.2.11-1 

The VM will communicate with the back office through a secure communications interface to send and receive and data 
including but not limited to: 

• Transaction information 

• Event (alarm and maintenance) status alerts 

• Time synchronization information 

• Positive/negative lists 

• Configuration parameters 

• Remote commands or status inquiries 

The list of communications information will be finalized during design reviews. 

4.5.2.11-2 

All communications between the VM and the next gen ORCA and VM back offices will be via the Ethernet interface. 

4.5.2.11-3 

If required for PCI certification, a second Ethernet port will be provided to transmit payment data separate from other 
transaction data. 

4.5.2.12-1 

The VM will be equipped with a modular, filtered power supply which will be connected to the incoming grounded 
electrical service. The power supply will be connected to the incoming electrical service (120 V) and deliver all of the 
necessary operating voltages for the machine. Voltages internal to the VM will not exceed 125 V. 

4.5.2.12-2 

A power switch will turn the power supply on or off, and will be separate from the main circuit breaker that removes all 
power to the VM. There will be no safety risks to maintenance personnel with the machine power turned off. 


4.5.2.12-3 


A GFCI duplex convenience outlet will be installed within the interior of each cabinet. This outlet will be protected by a 
separate circuit breaker internal to the machine enclosure and will be grounded. Current rating of GFCI will be defined at 
design review. 
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Number 






Capability 


Appropriate warning labels will be provided on or near any components or cables that may have hazardous voltages 
present. 


If the VM shuts down due to loss of power, upon restoration of power the machine will automatically resume 
operations._ 


The VM will be equipped with a supplemental battery power supply. This battery power supply will be used to allow a 
controlled shut down, including a transaction in process to be completed, in the event the incoming voltage falls below 
the reliable machine operating voltage or in the event of loss of alternating current (AC) power to the machine. Once 
rimarv cower is restored, the backup batterv will be recharged. 


The supplemental battery will be rated at four (4) years or 500 discharge and charge cycles. 


VMs will generate, store, and transmit a discrete data record for each transaction performed. 


Each sales transaction record will be unique and will include the following information, at a minimum: 

• Date and time 

• Device ID 

• Station/Location ID 

• Card/account number 

• Transaction type (e.g., card sale, value load, account inquiry) 

• Cards sold (where applicable) 

• Stored value or fare products loaded (where applicable) 

• Passenger type (e.g., adult full fare, youth, senior, disabled) 

• Transaction value (where applicable) 

• Payment type and amount 

• Transaction result (e.g., success, failure) 

• Transaction ID 

Transaction records details will be finalized during design review. 


VMs will maintain local data records in non-volatile memory in the event that communications to the back office system 
is unavailable. The local records will only be removed when verification of database storage of each record is received 
from the back office. 


Each VM transaction record will be unique and will include the following information, at a minimum: 

• Date and time 

• Device ID 

• Station/location ID 

• Fare media number 

• Transit account 

• Transaction type (e.g., card sale, value load, account inquiry) 

• Cards sold (where applicable) 

• Stored value or fare products loaded (where applicable) 

• Passenger type (e.g., adult full fare, youth, senior, disabled) 

• Transaction value (where applicable) 

• Payment type and amount 

• Transaction result (e.g., success, failure) 

• Transaction ID 

Transaction records details will be finalized during design review. 


The VMs will provide audit register counts for purposes of data tracking and analysis. The audit registers will store counts 
of specific events in non-volatile memory and will not be able to be modified or erased. 
































Capability 

Number 


Capability 


The audit registers will maintain counts and value of the following events as applicable: 

• New fare media issued 

• Fare product sold 

• Stored value loaded 

• Transit account inquiries 

• Cash transaction, by amount and denomination 

• Credit card transactions, by amount 

• Debit card transactions, by amount 

• Count of approved and denied transactions 

• Count of read failures 

Final audit register events will be determined during design reviews. 


Audit register records will be transmitted to the back office at the end of service day for reconciliation, or based on a 


(configurable time period. 


VM audit register records will be transmitted to the back office at the end of service day for reconciliation, or based on a 
configurable time period. 


The VMs will provide real-time status of device and module level events and alarms through the System Manager. The 
5.3.3-1 VM will also maintain local event and alarm logs in the event that communications to the back office is unavailable. 



.5.3.3-2 


In addition to transmitting real-time events and alarms, the VM will transmit periodic "heartbeat" messages that confirm 
communication with back office and basic status. The "heartbeat" frequency will be adjustable by VM._ 


Fully Conforming 
NonEonforming 
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Number 



Capability 


The VM will generate, store, and transmit alert information for relevant events, including but not limited to: 

• Power on 

• Power off 

• Reboot 

• Back office communications failed/restored 

• Maintenance parameter changed 

• New fare table received/activated 

• New software received/activated 

• New configuration data received/activated 

• New list received/activated 

• Anti-virus definitions and security updates downloaded 

• Internal clock reset 

• VM clock error 

• Data memory near full/full 

• Low battery 

• Failed bankcard authorization request 

• Defective media captured in reject bin 

• Maintenance technician login and logout 

• Maintenance parameter changed 

• Revenue service technician login and logout 

• Bill vault removed/installed 

• Coin vault removed/installed 

• VM "heartbeat" check 

• Software update from removable media initiated 

• Software update failure 

• Machine hardware configuration change 

• Module faults (coin/bill/card jams, low stock and change) 

• Security events 

• Vibration alert 

Final events and alerts will be determined during design reviews. 


The VM will monitor the contents of the media stock and transmit an event to the back office when the inventory is 
below a configurable threshold, and when the inventory is empty. 


The BHU will cease to accept bills and indicate a "no bills accepted" message on the display when the bill vault becomes 
full. 


The BHU will automatically reset all appropriate counters when the bill vault is removed and/or replaced. 


The coin acceptor will not accept coins once the vault has reached 90% capacity, or configurable amount. 


The smart card encoder/dispenser/SED will monitor the contents of the card stock and transmit an event to the back 
office when the inventory is below a configurable threshold, and when the inventory is empty._ 


Whenever the local alarm siren is active, the VM will go out of service. When the alarm condition ends, the VM will 
perform self-diagnostics, and resume normal operations. Events that are linked to the local siren and other alarms that 
result in the VM going out of service will be defined during design review. 


The VM will have capacity to locally store a minimum of one (1) year of event and alarm data. 


Each voice annunciation message will occur as close as possible to the event or change in transaction status as possible, 
and be as brief as possible to convey the necessary information._ 


The voice annunciation will support multiple languages including at least Simplified Chinese, Spanish, and English. 
Required languages will be finalized bv the Agencies during design review. 
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Capability 


When the headphone jack is used, a voice annunciation system with adjustable volume will provide context-sensitive 
voice messages, in audio form, conveying information shown on the device display to meet or exceed all applicable 
accessibilitv and ADA reauirements. 


The SI shall hire a third-party to provide audio and text translations. The audio/text translations will be submitted for 
Agency review and approval._ 


English will be the default language while the VM is in idle mode and the VM will return to English after a transaction is 
completed or cancelled. 


Supported languages will be provided by the Agencies during design review. 


The VM will include a selection button to change the display and the voice annunciation language between English and 
up to six (6) other available languages._ 


The alternate language button will be active at all times and available on all screens while the VM is in service. Pressing 
an alternate language button at any time will cause the display and audio messages to the selected language. 


For all transactions, the VM will display a progression of screens to the customer that will be easy to understand and 
intuitive. 


All information presented by the VM will be capable of being modified by authorized Agency staff. Modifications will be 
able to be made remotelv or bv removable storage media. 


The VM will provide the following core functions to support customer operations: 

• Sell one or more new fare media in a single transaction where the associated transit accounts are initialized only (no 
value) or are loaded with value 

• Load stored value and all available fare products to previously issued fare media (e.g., transit accounts) 

• Query the back office to retrieve the balance and transaction history for existing transit accounts 


The operating status and configuration for each VM will determine the available options. Only options that are enabled 
will be shown to the customer. 


A detailed customer operations document, including screen flows depicting "snapshots" of each screen layout arranged 
as a logical flow chart will be provided during FDR for Agency review and approval. 


Each VM will be ready to respond to a customer input when in the idle condition. Input may be a physical button push, 
touch screen input, or touching fare media to the contactless validator._ 


The VM "home" or starting screen, will include the following options at a minimum: 

• Purchase a new fare product 

• Reload an existing account 

• Check account/product balance 

• Language preference 

• Help button 

• "Express" purchase of a card/ticket with one (1) ride (configurable) 


The VMs will have clear instructions to indicate the steps a customer must follow to perform any transaction. The 
sequence of steps will be clearly indicated by the use of graphics and text. Wherever possible, universal graphics and 
symbols will be used that can be understood without having to read the displayed text. 


The VMs will have Agency-configurable distinctive audio tones to provide feedback each time a button is pressed. 


English-speaking customers will be able to purchase new fare media (with stored value or a pass) or load value to an 
existing card in a maximum of three (3) screens. 


For new fare media purchase transactions, the VMs will read and/or encode media as necessary to capture account 
numbers and initialize the media. The VMs will send the media data to the back office, along with all relevant fare 
purchase and payment information, to create and load the associated transit accounts, and generate sales transactions. 
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Number 

Capability 

4.5.4.3-12 

For fare media reload transactions, the external contactless validator will read (and, if necessary for risk mitigation, 
encode data to) the customer's card. The VMs will send the fare media data to the back office, along with all relevant 
fare purchase and payment information, to load the associated transit account, and generate a sales transaction. 

4.5.4.3-13 

For balance check transactions, the external contactless validator will read the customer's fare media. The VMs will send 
the fare media/ticket data to the back office to retrieve the associated balance and transaction history information. 

4.5.4.3-14 

All transactions will be individually recorded, stored, and transmitted to the back office by the VMs using the Sl-provided 
API. 

4.5.4.3-15 

All transactions will initiate communication with the account-based transaction processor (ATP) to query or modify 
transit accounts associated with the fare media in real-time. 

4.5.4.3-16 

In offline mode, the VMs will be able take cash payments to sell single rides or other limited fare products, in order to 
provide a means for customers to access transit services. The details of which products will be sold in offline mode, and 
the risk mitigations strategies to be employed (such as writing to the media), will be determined during design review. 

4.5.4.3-17 

When payment is required, the VM will automatically detect what form of funds the customer has inserted. Customers 
will not have to choose whether the transaction will be by cash or bank card. 

4.5.4.3-18 

If the VM loses communications with the back office, upon restoration, the VM will automatically initiate 
communications and send any data generated in offline mode. 

4.5.4.3-19 

When paying by cash, the VM will permit the customer to deposit coins and bills in any sequence. 

4.5.4.3-20 

Prior to authorizing a bank card transaction, the VM will prompt the customer to choose whether the purchase is a credit 
or debit transaction. For debit transactions, the VM will prompt for PIN entry. 

4.5.4.3-21 

The VM will support Address Verification System (AVS) for bank cards in a configurable manner that allows the AVS 
feature to be turned on or off by the Agencies and accommodates acceptance of both U.S. and non-U.S. issued cards. 
When a U.S. bank card is used for payment, the VM will prompt the customer to enter the billing address ZIP code. 

4.5.4.3-22 

All bank card transactions will be authorized prior to dispensing media or loading fare products. If a bank card is declined 
for any reason the VM will display related information to the customer and cancel the current transaction. 

4.5.4.3-23 

If bank communications are unavailable, bank card transactions will be disabled, and the VM will enter "cash only" 
mode. 

4.5.4.3-24 

The customer will have the capability to cancel a transaction at any point before full payment has been inserted in cash 
or a bank card authorization has been received. 

4.5.4.3-25 

If any failure occurs during a transaction, the VM will automatically cancel the current transaction and indicate the 
cancellation on the screen. 

4.5.4.3-26 

If a transaction is canceled automatically or by the customer, all inserted cash will be returned and credit/debit card 
transactions will be reversed as necessary. 

4.5.4.3-27 

The VM will be configurable to provide receipts: 

• Upon customer request 

• Automatically for transactions above a configurable dollar value, or optionally for transactions below the configurable 
value 

• For every transaction 

• Never (when receipt stock is empty) 
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Fully Conforming 

NonBonforming 

Comments 

4.5.4.3-28 

All receipts will have a printed indication that the receipt is not a valid ticket, and will contain at least the following 
information: 

• Machine number - up to eight (8) alphanumeric characters 

• Date - month, day, and the last two (2) digits of the year, totaling nine (9) characters 

• Time - four (4) digits separated by a colon and followed by two (2) letters "AM" or "PM," using a 12-hour clock 

• Station name or location where purchased - up to 16 characters 

• Card/account number 

• Last four (4) digits of credit/debit card number (PAN), if used as the form of payment 

• Value purchased and remaining balance (if applicable) 

• Transaction amount 

• Machine-unique transaction sequence number 

Final receipt information will be determined during design review. 

X 



4.5.4.3-29 

Receipts for bank card transactions will also include information as identified in Federal Regulations E and Z, and other 
information necessary to comply with banking and Federal regulations. 

X 



4.5.4.3-30 

The VM will employ an adjustable time-out period to return the VM to the idle state if no input is received between 
transaction steps. The time-out period will be adjustable by authorized staff. 

X 



4.5.4.3-31 

A screen saver may be activated after a programmable idle period has passed, and will support the following at 
minimum: 

• Static image in any common graphics format, e.g., JPG, TIFF, BMP, GIF 

• A repeating "slide show" of static images 

• Text messages and imported text-based files 

• Webpages and other dynamic markup language files 

• Pre-recorded video in any common format, including MPEG, WMV, MOV, AVI, H.264 

• Any combination of the above 

X 



4.5.4.3-32 

The screen saver will automatically terminate and the VM will display the home screen as soon as any button is pressed 
or a credential is presented to the contactless validator. 

X 



4.5.4.3-33 

For all new ORCA card purchase transactions, the time from acceptance of the cash payment or credit/debit card 
approval to media issuance will not exceed three (3) seconds. 

X 



4.5.4.3-34 

Where transactions produce multiple media, the time between successive media being deposited in the return tray will 
not exceed two (2) seconds each. 

X 



4.5.4.3-35 

When applicable, the receipt printer will deposit receipts in the return tray within three (3) seconds of the completion of 
a transaction. 

X 



4.5.4.3-36 

For completed or canceled transactions, VM readiness to begin another transaction will not exceed three (3) seconds. 

X 



4.5.4.3-37 

The FFVM will inform cash paying customers when an insufficient amount of change is available and provide the options 
of either canceling the transaction resulting in a return of the customer's cash from escrow or allow any overpayments 
associated with the EU fare media to be added as stored value to the associated transit account's E-purse. 

X 



4.5.4.3-38 

The VM will include a customer display screen bearing simple and easy to read instructions which sequentially instruct 
the customer how to perform available functions. 

X 
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Each VM will automatically perform self-diagnostic tests upon startup, and at adjustable regular intervals (once per day 
by default). Self-diagnostic tests will at minimum: 

• Confirm communications with back office 

• Check status of all major electronic modules 

• Exercise all electro-mechanical devices 

• Confirm all software and configuration files are up to date 

Any failures or exceptions identified during self-diagnostics will be recorded in the VM's internal audit registers and 
transmitted to the back office. 


Each VM will be capable of performing diagnostic tests that are manually initiated by service staff while the VM is out of 
service and the front door is open. 


Inside the VM will be a keypad and optional display for use by maintenance and revenue service personnel while the 
outer door is open. The customer display may be used for maintenance purposes if viewable while using the service 
kevoad. 


The service keypad will be used to enter access (login) codes and maintenance and diagnostic commands. All routine 
service interaction with the VM will be via this keypad. 


A failure to login using the keypad after opening the VM door will generate an intrusion alarm. 


The service display will be used to indicate VM error codes, and will have the capability of displaying multiple error 
codes, such that one error code will not need to be cleared to display other error codes. 


The VM will not commence in-service operation until the outer door is closed and the outer door lock is returned to its 
fully secured position. 


All access will be traceable through the System Manager and all access transactions will be individually recorded and 
transmitted to the System Manager at time of occurrence._ 


To support revenue servicing and maintenance authorized technicians, the VM will produce audit tickets, including but 
not limited to: 

• Coin vault removal/insertion 

• Bill vault removal/insertion 

• Software versions and VM configuration 

• VM revenue status 

• VM maintenance alert status 

Final audit ticket information will be determined during design review. 


Each audit ticket will indicate at minimum: date, time, VM number, technician name or number, and activity 
information. 


Automatic diagnostic test routines (and equipment if necessary) will be included to aid in troubleshooting malfunctions. 
These test routines will provide the ability to isolate defects down to the LLRU._ 


Section 5 Externally Sourced Applications 


Section 5.1 General Capabilities 


The customer website and mobile app will be compliant with all Title VI provisions. 


The System will allow registered and unregistered customers to load stored value and products via the customer website 
and mobile app using at a minimum credit card, debit card, or bank account (ACH) transfer. The customer website and 
mobile app will support the entry of transit account information and the selection of fare products and pre-defined or 
custom stored value amounts, subject to configurable minimum and maximum limits. 


During autoload setup, the customer will be able to select a primary and backup funding source. If payment 
authorization of the primary funding source fails, authorization against the backup funding source will be attempted. If 
ayment authorization is not received, the autoload will be automatically disabled._ 
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Capability 


38 

Registered customers shall be able to enable, disable, and modify the autoload of stored value and products. As part of 
the autoload setup process, the customer will select the stored value amount or product to be loaded and the type of 
autoload (e.g., threshold or periodic). Autoload setup will require a funding source to be added or selected and 
validated. 

5.1-5 

The SI shall provide a modern COTS content management system (CMS) for Agencies so that the Agencies can maintain 
and update the website. 

5.1-6 

The website will be built using modern web design and e-commerce best practices. 

MEM 

The customer website and customer mobile app will integrate with the ATP using the Sl-provided Transit Account 
Management API. 

5.1-8 

Customer account creation and transit account registration will be able to be performed using the customer website and 
mobile app. 

5.1-9 

Users will access the customer website and mobile app using the same user login. 

5.1-10 

The SI will deliver a customer website and mobile app and provide all back office third-party hosting access and software 
necessary to support website and mobile app operations, and integrations to internal and external applications needed 
to perform the required functions. 

5.1-11 

Registered customers will have the capability to view and modify customer account data. 

5.1-12 

The customer website and mobile app will support the association of multiple transit accounts to a single customer 

account. 


5.1-13 


5.1-14 


5.1-15 


5.1-16 


5.1-17 


5.1-18 


5.1-19 


The customer website and mobile app will be easy to use with simple processes for all transactions as demonstrated in 

user testing. _ 

The website and mobile app will have functionality for self-service password resets. 

The website and mobile app vendor will supply metrics that will allow the Agencies to evaluate success of web and 

mobile app customer interactions. _ 

The customer website and mobile app will allow customers to perform the following functions, at a minimum: 

• Purchase new fare media 

• Create a new customer account 

• View and manage account settings and customer profile 

• Register EU fare media (e.g., transit account) 

• Purchase fare products (e.g., stored value and passes) 

• Add, modify, or delete a funding source 

• Set up, modify, and cancel autoload of stored value and products 

• Transfer transit account balances consistent with adopted business rules 

• View transit account balance and status information 

• View and download sales, usage, and adjustment transaction history 

• Initiate a customer service request (e.g., refund request) 

• Report fare media lost or stolen 

• Request an opt-out refund (e.g., close transit account) 

Final customer mobile app and customer website functions will be determined during design review. 

Registered and unregistered customers will be able to use the customer website and mobile app to view transit account 
balance (e.g., stored value and pass) and status (e.g., passenger type, active or blocked) information by entering a fare 

media identifier. _ 

The customer website and mobile app will be provided in multiple languages, including English and up to six (6) other 

languages to be identified by the Agencies during design review. _ 

Registered customers will be able to add new credentials for the transit accounts when logged into the customer website 
or mobile app._ 


Fully Conforming 
NonEonforming 
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Password will be masked when presented on the website and mobile apps. 


5.1-21 


The website and mobile app password will have configurable security capabilities, including but not limited to minimum 
password length, required use of letters/numbers/symbols, and forced password reset after a configurable time period 
or on demand. 


The customer website will be designed and tested for cross platform compatibility, including popular platforms and 
browsers. Supported browser versions will include at minimum the most current and 2 previous major versions. Final 
version support will be determined during design review. 


5.1-23 


The website and mobile app will prompt users when a payment is declined and allow entry of an alternate funding 
source. Failed payments will be recorded in a separate payment exception file (with denial code). _ 


5.1-24 


During creation of a new customer account, the customer website and mobile app will provide the ability to link transit 
accounts associated with previously issued EU fare media. Fare media (e.g., transit account) linking will not be required 
to create a customer account. 


Customers will be able to assign each credential a nickname, which will be stored in the transit account and used to 
differentiate credentials registered to the same customer account. 


5.1-26 


The customer website and mobile app will support the payment, or partial payment, for the purchase of a pass or multi- 
ride product using stored value in same transit account where the product is being loaded. _ 


5.1-27 


The customer website and mobile app will allow registered customers to close a transit account and request a refund or 
transfer the E-purse balance to another transit account. This action will immediately result in the associated fare media 
being blocked from further use. The operational policies governing the issuance of a refund or transfer of products will 
be defined during design review. _ 


The customer website and mobile app will allow ordering of Agency-issued EU fare media to be delivered by mail. The 
customer website and mobile app will support the ordering of registered and unregistered fare media._ 


5.1-29 


The customer website and mobile app will include general information on use of the System, including an FAQ section, 
information on where to purchase fare media and value, customer agreements, and general program information and 
updates. 


5.1-30 


The customer website and mobile app will allow a customer to move a transit account from one customer account to 
another. The process will be defined during design review. _ 


Registered customers will have an Agency configurable option of initiating a customer service request via the customer 
website and mobile app. This action will automatically generate a request within the CRM application and assign the 
request to the appropriate customer service staff. _ 


The customer website and mobile app will include links to the Agencies' websites with schedules, fares, and other 
general transit information._ 


5.1-33 


The System will display a notification for account activity, such as successfully completed sales, fulfillment of autoload or 
low balance alerts. Users will have the option of additionally receiving the notification via push, email, or text. 


Section 5.2 Customer Mobile App 


5.2-1 

The SI will retain a qualified mobile app developer to develop and maintain the customer mobile app for Android and 
iOS. 

5.2-2 

The look and feel of the mobile app will be streamlined, modern, and have a clean, simple design. 

5.2-3 

The customer mobile app will follow the current design and accessibility guidelines for each operating system. 

5.2-4 

The customer mobile app will be tested and support the two most recent major versions of operating systems on the 
Android and iOS platforms on the day that the OS is released to the general public. 

5.2-5 

The display, instructions, and selection keys of the customer mobile app will be easy to read, understand, and use as 
demonstrated through user testing. 

5.2-6 

The customer mobile app will be available in the app stores, offered and maintained by the SI. 

5.2-7 

The customer mobile app will process payments through the System's Central Payment application. 
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5.2-8 


The customer mobile app will support the sale of all retail ORCA fare products in a similar manner to the customer 
website. 


The customer mobile app will make it easy for customers to purchase fare products as demonstrated through user 
testing._ 


5.2-10 


The customer mobile app will accept payment via mobile wallet. 


5.2-11 


The customer mobile app will allow for multiple types of fare products from multiple Agencies to be purchased in one 
transaction. 


The customer mobile app will support the display of transaction history and other transit and customer account 
attributes in a similar manner to the customer website. 


The customer mobile app will have the ability to act as a fare payment credential at onboard, wayside, or mobile 
validators. This will be done using a next gen ORCA closed-loop credential stored on an NFC-enabled device. 


The customer mobile app will allow a customer to procure a mobile closed-loop credential through in-app provisioning 
without the need for a physical card. The customer mobile app will also enable conversion of a physical credential to a 



mobile credential if a card has already been procured by the customer. 

5.2-15 

The customer mobile app will communicate with the validators via ISO/IEC 14443 and the back-end system to recognize, 
log, and report on the usage. 

5.2-16 

System must be able to validate fare products presented via the customer mobile app with no interaction from 
operators. It must not require that Agency personnel touch customer devices. 

5.2-17 

Fare presentation and validation must be able to occur when the customer mobile device is not internet-connected. 

5.2-18 

The customer mobile app will generate and transmit additional data that enables and supports comprehensive reporting 
and analytics including mobile platform information and geocoding. 

5.2-19 

The System will be able to report on anonymized usage patterns of the customer mobile app by authorized users. 

5.2-20 

The customer mobile app will enable the addition of marketing and advertising on mobile platform for increased 
revenue opportunities for the Agencies. 

5.2-21 

The customer mobile app will include functionality to offer promotions to customers from local retail partners. 

5.2-22 

The customer mobile app will include functionality to manage promotions based on geofences. 

5.2-23 

The customer mobile app will include surveys that will facilitate the gathering of customer service metrics and ease of 

use. 

5.2-24 

The customer mobile app will include functionality to send Agency messaging outside of the alert functions on mobile 
phones, e.g. via email or SMS. 

5.2-25 

The customer mobile app will include links to trip planning applications (e.g., Google Maps, Apple Maps, Transit App, and 
Puget Sound Trip Planner). The links will be configurable centrally and by the customer on their device. 

5.2-26 

The customer mobile app will include links to transportation network company applications (e.g., Lyft and Uber). The 
links will be configurable centrally and by the customer on their device. 

5.2-27 

The customer mobile app will enable integration with social media functions, including marketing, promotions, 
discounts, route information, etc. 


Section 5.3 Agency Mobile Apps 


5.3-1 

The SI will retain a qualified mobile app developer to develop and maintain the Agency mobile app(s) to be used by 
Agency personnel to perform next gen ORCA activities. 

5.3-2 

The Fare Validation mobile app will be able to collect closed-loop fares using a NFC-equipped handset. 

5.3-3 

The Fare Inspection mobile app will enable the inspection of closed-loop electronic fare media. 

5.3-4 

Download and use of the Agency mobile apps will be controlled so access is limited to authorized Agency 
personnel/devices. 


Fully Conforming 
NonEonforming 































































Capability 

Number 

Capability 

Fully Conforming 

NonBonforming 

Comments 

5.3-5 

The Program needs the SI to provide a means of updating the Agency mobile apps that is fully consistent with the next 
gen ORCA change management process. The updates will be delivered electronically over network connections and will 
not require user intervention unless called for in the change management process. 

X 



5.3-6 

The Fare Inspection and Fare Validation mobile apps can be combined. If they are combined user access will allow for 
users with full access (both applications) and users with access to only inspection or validation. 

X 



5.3-7 

The Fare Inspection mobile app and the Fare Validation mobile app will be in native Android version only. 

X 



5.3-8 

The Agency mobile apps will be designed to be used on any device meeting the to-be specified capabilities, and will work 
on a variety of devices (both phones and more traditional fare inspection devices) of the Agency's choosing. 


X 

Normal android devices are supported. Special devices need to be evaluated on case-by-case basis. 

5.3-9 

The Agency mobile apps running on Agency-provided devices will require remote management. The Agencies will 
approve the specific method during design. Management could be through the System Manager, an Sl-provided Mobile 
Device Management (MDM) solution or an MDM already in place at the Agencies. 

X 



5.3-10 

The Program needs the SI to provide a System Manager and/or MDM solution which will include remote management 
and Over The Air (OTA) capability to lock or disable the Fare Validation and Fare Inspection mobile apps. Agencies will 
maintain MDMs to locate, lock, disable, or erase mobile devices. 

X 



5.3-11 

The Fare Inspection and Validation mobile apps will support user login and identify service type and location. 

X 



5.3-12 

The Fare Validation mobile app will operate in a similar fashion to the onboard and wayside validators. All interactions 
with fare media will be identical to interactions driven by onboard and wayside validators. All data returned to the back 
office will use the same APIs and be as similar as possible to that returned by wayside and onboard validators. 


X 

In order to follow the agency's BYOD requirement, avoid dedicated payment terminal hardware and 
storing keys to unsecure devices the following exceptions to the logic need to be allowed: 

- At this point of time there is no technical solution to read virtual cards stored in Google Pay and 
Apple Wallets using an NFC device for validation and inspection purposes. We are watching the 
market and there is movement that a sleeve will be available soon that will allow fare inspection of 
virtual cards using NFC. We are confident that this will allow NFC fare inspection and validation 
before launch of the next generation ORCA system. But since there is currently no technical solution 
we have to make the following exception 

- The Inspection and Validation App will read and validate barcodes on the Apple and Android Wallet 
virtual ORCA cards instead of reading the transit account ID over NFC. This exception is only 
applicable to virtual cards. For physical cards the app will read out the card number using NFC. We 
hope that there will be a technical way to inspect virtual cards using NFC in the future. In our 
standard solution no transaction data is written to the card since this would require the card keys to 
be stored on an unsecure device. We are open to discuss an alternative approach that would allow 
the inspection app to write information to the card. The basic idea is to use a second card application 
on the card that is accessible / writable without a card key. The security would be added using a 
signature approach. The final approach would be determined during the system design phase. 

5.3-13 

Fare validation and inspection mobile apps must be capable of operating when the mobile device is not internet 
connected. 

X 



5.3-14 

The Fare Validation mobile app will utilize the mobile device's GPS source. 

X 



5.3-15 

The Fare Inspection mobile app will use a real-time connection via the SI provided Fare Inspection API to process fare 
inspections. 

X 



5.3-16 

The Fare Validation mobile app will use a real-time connection to the ATP through the SI provided Fare Payment API for 
processing payments. 

X 



5.3-17 

The Fare Validation and Inspection mobile apps will provide a visual and audio indication for validation results as 
approved during system design and demonstrated during user testing. 

X 



5.3-18 

The Fare Validation mobile app will keep a transaction history for offline recording of fare payments. 

X 



5.3-19 

Enforcement rules for fare inspection will be received from the ATP through the System Management API. The rules will 
be clearly presented on the inspection device. 

X 



























Capability 


Number 

Capability 

5.3-20 

All mobile inspections will generate transactions for reporting, analysis, and traceability. 

Section 5.4 Customer Website j 

5.4-1 

The SI will contract with a web design firm or developer with extensive experience developing e-commerce, retail, and 
social media websites to develop the customer website. 

5.4-2 

The System will provide, at a minimum, the capability for customer account management business rules to be different 
for different types of customer accounts for the purposes of: 

• Payment for services as defined by mode, including precedence of fund usage (for example, you cannot use pre-tax 
funds to pay for an auto on ferries). 

• Refunds and fund transfers to customers. 

• Employer and employee contributions of both tax-free/pre-tax funds and non-tax benefit funds. Any pre-tax funds will 
be added to the account by the employer. 

5.4-3 

The functionality will comply with the Commuter Tax Benefits legislation requirements as defined in Section 132(f) of the 
Internal Revenue Code for pre-tax funds. 

5.4-4 

The look and feel of the customer website will be streamlined, modern and have a clean, simple design. 

5.4-5 

Access to customer website functions, features, and data by customers will be controlled by user roles. The roles will 
vary from administrative roles to roles with very limited rights. 

5.4-6 

Registered customers will be able to view no less than 18 months of prior transaction history, showing all sales, usage, 
and adjustment transactions. The transaction history will be viewable and sortable on the customer website, and able to 
be downloaded in PDF and Excel formats. 

5.4-7 

Customer accounts will be created using the customer website. Customers wanting to purchase products that require 
documents or forms will go through an approval process prior to products being added to the transit accounts. 

5.4-8 

The customer account sign-up process will capture all necessary customer account data (e.g., username, password, 
contract, address, payment methods) as required for the customer account type. 

5.4-9 

The customer website will support the administration of transit benefit programs by customer administrators and third- 
party administrators. 

5.4-10 

The customer website will allow employers, schools, social service agencies, and other organizations to order fare media 
and load transit accounts. 

5.4-11 

The customer website will have the ability to support pre-tax transit programs. 

5.4-12 

The customer website will provide the following functions at a minimum. Availability of some of these functions will be 
configured by customer account type and user role. Design activities will determine the functions that will be 
configurable: 

• Register a new account (e.g., create a new individual or business customer) 

• Associate transit accounts with a customer account 

• Disassociate transit accounts from a customer account 

• Load value (e.g., stored value E-purse and products) to transit accounts 

• Block transit accounts (e.g., fare media) and/or use of loaded value 

• Bulk order EU fare media 

• Make a payment 

• View order history, invoices, and payment status 

5.4-13 

The System will provide a process for ordering and tracking bulk media purchases. Customer account administrators will 
be able to manage bulk sales through the website (if bulk sales have been configured for the customer account type). 


5.4-14 


The customer website will allow customer account administrators to manage the association and disassociation of transit 
accounts individually or in bulk._ 


Fully Conforming 
NonEonforming 
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Number 
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5.4-15 

The System will assign a unique account ID to each customer account. 

5.4-16 

The customer website will have the ability to manage organization- provided parking benefits. 

5.4-17 

If configured for their customer account type, the customer website will enable customers to add value to transit 
accounts and subsidize part or all of a stored value E-purse, multi-ride product, or pass purchase made by their 
employees or members through any customer interface within the next gen ORCA system. 

5.4-18 

The customer website will provide customer account administrators the ability to place orders for any approved next gen 
ORCA fare product, and manage the transit accounts associated with their customer account. 

5.4-19 

The System will support employer programs directly administered by customers as well as those administered by third 
parties contracted to customers to provide commuter tax benefits. 

5.4-20 

The System will have the ability to add new products through a configurable interface. 

5.4-21 

The customer website will allow a customer account administrator to add additional users or third-party administrators 
to manage the customer account, transit accounts and programs. 

5.4-22 

The effective date of Passport Products will be updated when the end date of the customer's contract changes. 

5.4-23 

The customer website will allow customer account administrators to manage product validity duration and the 
expiration of Business Passport fare products. 

5.4-24 

The customer website will integrate with the CRM application using the SI provided APIs. 

5.4-25 

The customer website will use the following APIs for integration: 

• Transit Account Management API to integrate with the ATP 

• Customer Account Management API to integrate with CRM application and Accounts Receivable (AR) and Billing 

5.4-26 

The System will allow rules related to dollar limits and qualified services to be configurable by the Agencies for both 
Business Choice and Business Passport programs. 

5.4-27 

The customer website will provide administrators the capability to view summary level reports on their organization's 
activities including usage. However, customer account administrators will not be able to see individuals' transactions. 

5.4-28 

The System will have the ability to provide reports on customer account product usage. 

5.4-29 

The customer website will have the ability to track the status of orders. 

5.4-30 

The customer website will support the import of data, such as employee lists, for customers applying for a reduced fare 
classification. Imports include basic data, scans of applications and supporting documentation, eligibility parameters, and 
fare media personalization information, such as a customer photograph. Access to this ability will be controlled by 
customer account configuration. 

5.4-31 

Customer account administrators will be able to view current payment status (e.g., balance due, accrued interest, and 
due date) and at least 25 months of invoices, and order and payment history, via the customer website. The invoices, 
orders, and payment history will be viewable and sortable on the website, and able to be downloaded in PDF and Excel 
formats. 

5.4-32 

The System will provide the capability for the creation of a hierarchy of customer accounts with parent child 
relationships. 

Section 6 Back Office Applications 

Section 6.1 General Capabilities 

n 

The SI shall develop and submit for Agency approval during design review a back office hardware design specification 
that provides a detailed description of all hardware components that will comprise the back office, and the purpose, 
functions, interdependencies, configuration, and communication capabilities of each component. 

6.1-2 

Back office applications and data structures will all be able to expand to support additional agencies without 


6.1-2 


reprogrammin] 
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Number 

Capability 

6.1-3 

The back office system will provide access to no less than seven (7) years of historical data. Deletion and archiving of data 
will be supported as agreed by the Agencies. 

6.1-4 

The back office will retain detailed active transactions for at least 25 months. 

Section 6.2 Account-based Transaction Processor [ 

6.2.1-1 

The ATP will enable core system functions, including but not limited to: 

• Fare media sales and issuance, and the creation of new transit accounts 

• Fare product sales and the loading of fare products (e.g., stored value, multi-rides, and passes) to transit accounts 

• Maintenance of transit account status, balance, and transaction history 

• Real-time fare calculation and payment processing (e.g., validation) for closed-loop fare payments 

• Real-time fare payment inspection for closed-loop fare payments 

• Automatic reloading of value to transit accounts (e.g., autoload) 

• Modification of transit account balances based on adjustments, refunds, reversals, and balance transfers 

• Blocking/unblocking and closing of transit accounts 

• Setting of all specified transit account management configuration parameters (e.g., fraud detection parameters, 
negative balance limits, etc.) 

6.2.1-2 

The fare distribution, payment, and inspection devices, and supporting back office applications, will access the ATP 
functions using the Sl-provided API and a direct, real-time connection to the ATP. 

6.2.1-3 

The ATP will maintain transit accounts that store all stored value, multi-rides, and passes loaded by customers, and 
deduct value in real-time as accounts are used for payment. 

H 

The ATP will support all customer service functions impacting transit account status and balance that are available 
through all customer service channels using Sl-provided devices and systems, including the CST, CRM application, 
customer website, and customer mobile app. 

6.2.1-5 

Transit account balance information will include the current stored value balance and the state (e.g., active/inactive) and 
remaining validity (e.g., expiration date or rides remaining) of all products. 

6.2.1-6 

Minimal transit account personalization information (e.g., customer/card name, passenger type, and DOB) may also be 
stored securely in the transit account to support fare processing and allow for the individual tracking of fare media 
associated to the same customer. 

B 

The sale of specific types of fare products and the issuance of transit accounts by passenger type may be optionally 
restricted to transit accounts that are associated with customer accounts only. Restrictions will also be configurable 
according to customer account type. 

6.2.1-8 

All equipment will be able to receive multiple lists from the back office including, but not limited to, positive and 
negative lists. These lists will help improve passenger dwell time and mitigate risks from offline operation. All local lists 
will be updated based on changes since the last update at a configurable interval of no less than every five (5) minutes. 

6.2.2-1 

All payment will be accepted or authorized prior to the loading of any fare value or products. Following payment 
confirmation, the ATP will update the transit account balance in real-time to allow for immediate use by the customer. 

6.2.2-2 

The ATP will support the real-time loading of fare products through all fare distribution channels. No loading of fare 
value to a transit account will be permitted without an active connection to the ATP. 

6.2.2-3 

The ATP will manage the automatic reloading of value or fare products that are configured for autoload. Autoload will be 
based on configuration parameters, and will require the transit account to be registered with a valid funding source, 
such as a credit or debit card or bank account (ACH) stored in the associated customer account 

n 

The account-based nature of the System will allow for autoload payment authorization to occur prior to the loading of 
any value, and immediate use of the value by the customer once the load occurs. If payment authorization fails, 
appropriate action will be taken as approved during design review. 
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6.2.2-5 

A customer account will be able to have two (2) funding sources associated with a transit account autoload, a primary 
funding source and a secondary funding source. The customer may split payment between them or use the secondary 
funding source as a backup in the event that the primary fails. 

6.2.2-6 

The autoload feature will support both threshold-based triggers (i.e., reloading when the stored value balance, 
remaining trip balance, or remaining validity period falls below a configurable threshold), and calendar-based triggers 
(i.e., reloading on a configurable date every month). 

6.2.2-7 

The System will have the ability to segregate any value loaded using pre-tax dollars, including the segregation of value 
purchased using pre-tax transit funds and pre-tax parking funds. 

6.2.2-8 

The System will have the ability to restrict the use of pre-tax and tax-free funds to qualified services (for example, 
transit/vanpool and commuter parking). 

6.2.2-9 

The System will allow after-tax E-purse to be used on all services, including transportation connections that have 
payment integration. 

6.2.3-1 

The real-time fare calculation performed by the ATP will be based on the fare tables. The calculation will incorporate all 
attributes of the ride being taken, such as transit account passenger type, transit account balance, available fare 
products and order of precedence rules, transfer status, and all other factors that influence the fare to be charged. The 
fare payment calculation algorithm will be presented for Agency review and approval at design review. 

6.2.3-2 

The Program needs the SI to design, develop, and implement the ATP to include a fare calculation engine, and the 
configurable fare sets, business rules, and transaction processing necessary to support the current fare structure and all 
of the fare structure configuration capabilities. 

6.2.3-3 

The System will support refunds of unused or partially used products. An Agency may at their discretion close a transit 
account and block the stored value E-purse or product in the transit account and refund the money to the customer. 

n 

When processing a fare payment, the ATP will provide an online server authorization in less than 500 milliseconds, and 
will query the transit account, perform fare calculation, and update the account balance, prior to providing an approval 
or denial response to the fare payment device. 

6.2.3-5 

The online-mode fare payment response generated by the ATP will include at minimum: 

• Payment status (e.g., success or failure) 

• Transit account passenger type 

• Fare product used 

• Fare charged 

• Remaining balance 

• Transfer time remaining 

• Product expiration date 

Other relevant transaction data may be included and identified during design review. 

6.2.3-6 

When real-time communications are not available, device-level fare payment authorization may occur using the risk 
mitigation techniques. Transaction data will be sent to the ATP, and processed to update the transit account status and 
balance, as soon as communications are reestablished. Any device-authorized transactions will be recorded as such, so 
that offline transactions can be easily identified and tracked. The offline fare payment authorization algorithm will be 
oresented for Agencv review and aDoroval at design review. 

6.2.3-7 

The fare calculation process will check the transit account's passenger type. If passenger type is not applicable to an 
Agency or is expired, the System will apply the configurable default passenger type to the fare calculation. 

6.2.3-8 

The ATP will accommodate late arriving transactions through the recalculation of individual fare payments, or the total 
fare due for a prior accounting period. Transactions occurring within an accounting period may remain in a pending state 
until that account period (e.g., service day) is closed. Transit account transaction history and balance information will be 
updated in real-time as transactions are received, and reflect any recalculation performed as a result of late arriving 
transactions. 
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6.2.3-9 

The ATP will support the tracking of negative stored value balances that occur as a result of offline fare payment 
acceptance or Agency configured fare policies. 

6.2.3-10 

Pass products will be able to be configured to grant a full, partial credit or no credit towards a fare for a premium 
service. In this scenario the remainder of the fare, or "upgrade fare," will be deducted from stored value. If the customer 
does not have enough stored value E-purse in their transit account to cover the upgrade fare, the upgrade fare may be 
paid with cash or transaction could be declined, depending on configurable business rules. 

6.2.3-11 

The System will calculate whether an upgrade for a pass product is required (i.e., if the fare is higher than the face value 
of the pass) and deduct it automatically from stored value E-purse. If there is insufficient stored value, then pass holders 
will also have the option to pay upgrades using cash. 

6.2.3-12 

For trips paid with stored value E-purse, the System will support the granting of transfer fare credits for all boardings 
that occur within a specified time of the initial tap at a validator for fare payment. The transfer period (i.e., time during 
which a boarding is eligible for a transfer) and Agency participation will be configurable. 

6.2.3-13 

The System will support inter-agency transfers for free or with an upgrade. For Agencies participating in regional 
transfers, inter-agency transfers will be free for customers transferring to routes or services with the same or lower fares. 
For customers transferring to routes or services with higher fares, an upgrade fare will be charged equal to the 
difference between the applicable fares. Upgrade fares may be paid from stored value or with cash. If cash not paid or 
accepted for uograde. transaction would be declined. 

6.2.3-14 

The System will limit inter-agency transfer credits to the Agencies participating in regional transfers. Agency participation 
in regional transfers will be configurable. Transfer rules regarding allowable connecting trips will be configurable by the 
region. 

6.2.3-15 

The System will restart the transfer window time anytime that stored value E-purse is used (i.e., when a customer pays 
an upcharge when transferring to a more expensive service, the transfer window is reset). 

6.2.3-16 

The System will support intra-agency transfers for free or with an upgrade. For Agencies with intra-agency transfers, the 
intra-agency transfers will be free for customers transferring to routes or services with the same or lower fares. For 
customers transferring to routes or services with higher fares, an upgrade fare will be charged equal to the difference 
between the applicable fares. Upgrade fares may be paid from stored value or with cash. If cash is not paid or accepted 
for an upgrade, the transaction would be declined. For Agencies not participating in regional transfers, intra-agency 
transfer oolicies will be configurable bv Aeencv. 

6.2.3-17 

The System will support intermodal transfers between transit services and transportation connection services. Transfers 
will be configurable to grant full or partial credit towards a fare. Transfer policies will be configurable for each 
transportation connection service and by Agency. 

6.2.3-18 

For fare payment, the System will have defined business rules related to conditions under which each product can be 
used. Agency products will be configurable by each Agency. 

6.2.3-19 

Transfer credits will be applied to transit accounts. 

6.2.3-20 

Order of precedence rules will be configurable to identify the order in which valid fare products will be used (i.e., first 
check for business pass, then for local Agency pass, then for regional pass before using stored value E-purse). The order 
of precedence rules, to be defined during design review, will determine which fare products are used first and under 
which scenarios. 

n 

Real-time fare inspection determination by the ATP will be based on the fare structure configuration. The determination 
will incorporate fare payment transactions (e.g., approved and denied) recorded by the ATP, transit account passenger 
type, available fare products, transfer status, and all other factors that influence possible payment by the customer. The 
online fare inspection algorithm will be presented for Agency review and approval at design review. 


6.2.4-2 


When processing a fare inspection, the ATP will provide an online server response in less than 500 milliseconds and will 
query the transit account to determine the inspection result prior to providing a confirmation of fare payment. Server 
authorization rate capabilities are specified in the Performance Measurement section. 
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The online fare inspection response generated by the ATP will include at minimum: 

• Payment status (e.g., valid or invalid) 

• Transit account passenger type 

• Fare product used (if valid tap is found) 

• Fare charged (if valid tap is found) 

• Transfer time remaining (if valid tap is found) 

• Transit account balance 

• Fare payment transaction history 

If the payment is determined to be invalid, an associated reason code will be provided (e.g., no tap, blocked card). Other 
relevant transaction data may be included and identified during design review. 


When real-time communications are not available, device-level fare inspection may occur using the risk mitigation 
techniques. Local positive and negative fare media lists will be refreshed frequently from the ATP. Transaction data will 
be sent to the ATP as soon as communications are reestablished. 


The Regional Reduced Fare Permit is an identification card issued on an ORCA card for use as proof of eligibility to pay a 
reduced fare. An RRFP card is required for senior or disabled passengers paying a reduced fare. Medicare customers are 
also eligible for the permit. The permit holder must pay the amount of the reduced fare on each Agency used, and use of 
the permit is subject to any time restrictions in effect for each system. The System will support the use of the RRFP by 
individuals who are age 65 or older or meet the disabilitv eligibilitv criteria. 


The System will support stored value, which will serve as an electronic cash-equivalent, and will be accepted for payment 
across all modes and services. When stored value is used for payment, the System will deduct the correct fare at each 
boarding or entry in real-time from the transit account, based on the fare pricing configuration._ 


A transit account may only have one passenger type associated with it. 


The System will support rolling products that are valid for unlimited rides on services costing at or below the face value 
of the product for a pre-defined period starting at product activation, which may occur upon sale or first use. Rolling 
products will be configurable to be valid for a continuous duration from 30 minutes to two (2) years (e.g., valid for 24 
hours from first use), or bounded by a service period (e.g., valid from first use through the end of the service day). 


A passenger type must be defined for each transit account. The default passenger type that will be associated with a 
transit account will be the Adult full fare passenger type. Passenger types include but are not limited to: 

• Adult full fare 

• Senior 

• Disabled 


Additional passenger types will be able to be defined. 


Adult full fare customers will have the option of associating a transit account with a customer account or remaining 
anonymous. 


Passenger types will be able to be modified and configured manually, or automatically based on customer date of birth 
or the granting of a temporary classification with a configurable end date. 


Not all Agencies offer a separate fare for all passenger types. The System will determine the applicable fare associated 
with each passenger type for each transit Agency._ 


Each transit account will be designated by passenger type (e.g., adult full fare, youth, senior, disabled, low income) and 
the transit account will be charged when fare is paid. 


For age-based passenger types, the date of birth will be stored in the transit account only. 




6.2.5.1-10 
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6.2.5.1-11 

For passenger types that are issued on a temporary basis (e.g., temporary disabilities, low income, youth), the System 
will generate automatic notification (via email and/or text) to the account holder that the fare discount will be expiring 
and renewal is required. Content of the notification will be configurable. Notification will be reviewed and approved 
during svstem design. 

6.2.5.1-12 

When a youth turns 19, the System will convert the passenger type from youth to adult full fare automatically. 

6.2.5.1-13 

All customers will each be required to have and present their own fare medium. 

6.2.5.1-14 

The System will be able to support a variety of fare structure configurations at system launch and in the future. Fare 
structure includes the supported fare policies, fare media, fare products, and distribution channels through which 
customers purchase fare media and products. The fare structure will be configurable by the Agencies, and designed to 
create a simple, unified system that enables interoperability across current and future transit modes without additional 
development. The fare policies will be supported, along with the detailed fare structure configuration capabilities. 

6.2.5.1-15 

The System will support single-tap or "flat" fare pricing that is fully configurable based on the following parameters at a 
minimum: 

• Agency 

• Passenger type 

• Mode 

• Service type 

• Route 

• Trip 

• Location 

• Day and time 

• Discounts 

These fare pricing parameters will also govern the acceptance or denial of fare products being used for payment and the 
granting of transfers. 

6.2.5.1-16 

The System will support zone-based fares. 

6.2.5.1-17 

The System will support route-based and service-based fares for premium pricing for certain types of service (e.g., 
express service). Fare pricing will be able to be configured for a single route or groups of routes. 

6.2.5.1-18 

The System will support location-based fares, or the capability to price fares based on the location of payment (e.g., 
boarding at specific stop locations). Location-based fare pricing will be able to be configured based on the stop location 
associated with wayside validators. 

6.2.5.1-19 

The System will support fare pricing based on the time of day and day of week (e.g., peak and off-peak fares). Peak/off- 
peak fare pricing will be able to be configured for specific fare products, passenger types, modes, and service types, and 
put into effect at all times or on a scheduled basis (e.g., every weekday). In addition to time of day, the System will 
support peak/off-peak pricing for specific trips. 

6.2.5.1-20 

For distance-based fares, the maximum fare from boarding location will be deducted from stored value E-purse at tap 
on. Upon tap off, final fare would be calculated and customer will receive credit back to their stored value E-purse, if 
applicable. 

6.2.5.1-21 

The System will support station-to-station fares and the ability to price fares based on the location of boarding and 
alighting. This distance-based fare pricing will be able to be configured based on the station location associated with 
wayside validators. 

6.2.5.1-22 

Each Agency will be able to configure fare structure and pricing for each mode and service type. 

6.2.5.1-23 

The service day will be configurable by each Agency. 

6.2.5.1-24 

The System will have the flexibility to support Agency fare changes without software modifications. All fare changes will 
be through fare table and other configuration changes. 


Fully Conforming 
NonEonforming 


















































Capability 

Number 

6.2.5.1- 25 

6.2.5.1- 26 

6.2.5.1- 27 

6.2.5.1- 28 

6.2.5.1- 29 

6.2.5.1- 30 

6.2.5.1- 31 

6.2.5.1- 32 

6.2.5.1- 33 

6.2.5.1- 34 

6.2.5.1- 35 

6.2.5.1- 36 

6.2.5.1- 37 

6.2.5.1- 38 

6.2.5.1- 39 

6.2.5.1- 40 

6.2.5.1- 41 

6.2.5.1- 42 


Capability 

The bus operator will be able to override the default fare via the DDU in order to support zone-based fares. 

The System will support both Agency-specific and regional fare policies and products, including stored value E-purse, 
transfers, reduced fares for eligible customers, regional daily and monthly pass products, multi-ride products, programs 
that require riders to pre-qualify (e.g., RRFP, youth fares, low-income program), regional programs by customer account 

type, and Agency-specific programs. _ 

The capability to load a particular fare product to a transit account will be configurable based on the fare product type 

and passenger type associated with the account. _ 

The System will support regional products such as the following for all participating Agencies: 

• Regional Monthly Pass: regional ORCA calendar monthly passes available in face values that correspond to transit 
Agencies' fares, accepted by participating Agencies for payment of trip fares up to the face value of the pass. 

• Regional Day Pass: regional ORCA rolling day passes accepted by participating Agencies for fares up to specified face 
values. Additional fares are required for one-way fares higher than the specified face values. 

The System will support date-based and promotional pricing that offers discounted fares on a temporary and permanent 
basis, up to and including the offering of free fares. Discounted fare pricing will be able to be configured for specific fare 
media types, passenger types, modes, service types, and routes, and put into effect indefinitely or for a defined period. 

The System will provide the ability to manage value for multiple transit accounts in a single customer account. The 
customer account will permit the payment of multiple fares by associating transit accounts to the customer account. 

The System will enable customers to use stored value E-purse to purchase fare products. 

Customers will be able to define threshold and calendar-based autoloads for transit accounts based on parameters set 

by Agency staff. _ 

The System will enable a customer to set up autoload to reload stored value E-purse and/or fare products. 

The loading of stored value will be restricted based on configurable parameters, including the minimum and maximum 

amount that can be loaded in a single transaction. _ 

Customers will be able to load value to their stored value E-purse (including via autoload) as long as the E-purse value 

does not exceed the regional maximum allowable value. _ 

Customers will be able to load value to their stored value E-purse via autoload as long as a regionally-determined 

configurable minimum number of days have elapsed since the last autoload of the E-purse. _ 

Customers will be able to load value to their stored value E-purse via autoload as long as the number of E-purse 

autoloads does not exceed the regional configurable maximum allowable number of autoloads for the month. _ 

All parameters governing threshold and calendar-based autoloads will be fully configurable by Agency staff, including the 
enabling or disabling of an autoload, threshold value (e.g., trigger), funding source, and fare product and/or amount to 

be loaded. Final configuration parameters will be defined during design review. _ 

The System will support calendar products that are valid for unlimited rides during a pre-defined calendar period for 
rides on services costing at or below the face value of the pass. Calendar products will be configurable to be valid for any 
calendar period from one (1) day to two (2) years, including periods that are bounded by specific dates (e.g., valid from 

Aug. 16 through May 14). _ 

Monthly passes and fixed period products expire at the end of the validity period. 

The System will enable the configuration of vending windows for monthly passes and fixed period products (e.g., 
summer youth pass). Vending windows may vary for Agency-specific and regional fare products. No discounts on prices 

for partial months will be offered. _ 

Monthly products will be configurable to extend the validity to the end of the last service day. This validity period will be 
configurable bv Agency. 






















































Capability 

Number 

Capability 

6.2.5.1-43 

Certain reduced fare passenger types will require association to a customer account. 

6.2.5.1-44 

Unused rolling period pass products (e.g. short-term Passport products, day passes) can expire. Expiration will be 
configurable. Validated rolling period pass products expire at the end of the validity period. 

6.2.5.1-45 

Day products will be able to be configured to extend the validity to the end of the service day. This validity period will be 
configurable. 

6.2.5.1-46 

Day passes and short-term Passport products (e.g., convention passes) will activate upon first tap and the validity period 
will be configurable to accommodate specified transit days. 

6.2.5.1-47 

The System will support trip-based multi-ride products that are valid for a pre-defined number of trips. Multi-ride 
products will be configurable to be valid for anywhere from one (1) to 100 trips, and to include transfer privileges or not. 

6.2.5.1-48 

Unused multi-ride products will expire a number of days from date of purchase, configurable by product. 

6.2.5.1-49 

The System will allow special products for a group of customers (e.g., school field trips) represented on a single closed- 
loop EU card. 

6.2.5.1-50 

The System will support the sale of fare products sold in bulk at both face value and at special discounted prices to 
approved users, configurable by fare product. 

6.2.5.1-51 

Transit accounts will be able to contain multiple fare products simultaneously (e.g., stored value and a pass product). 

6.2.5.1-52 

A transit account may contain multiple rolling period pass products (e.g., day passes). However, only one product of the 
same type will be able to be active at a time. 

6.2.5.1-53 

A transit account may not contain two fixed period pass products of the same type that are valid for the same or 
overlapping periods (e.g., fare media may contain May and June PugetPasses, but not $2.75 and $3.50 PugetPasses for 
May). 

6.2.5.1-54 

Stored value E-purse and fare products will be subject to a passback delay period at the point of fare payment, 
configurable by Agency, device type, and mode. 

6.2.5.1-55 

The System will accept Agency-issued next gen contactless ISO-14443 compliant smart cards, as well as existing smart 
cards, that are associated to next gen transit accounts and may be used to pay fares using stored value or fare products. 

6.2.5.1-56 

The System will support replacement card fees, which will be able to be configured based on passenger type and 
replacement thresholds (e.g., the first replacement is free and each successive replacement associated with the same 
transit account is $5). 

6.2.5.1-57 

Business Passport is a program that will provide transit passes for all transit services under a Business Passport 
agreement, with the ability to configure products to be valid only on specified transit Agencies and for a specific period 
of time. 

6.2.5.1-58 

When adding value to transit accounts associated with customer accounts, customer account administrators will be able 
to select from the available fare products configured for their customer account, and choose whether to initiate a one¬ 
time or recurring load (e.g., autoload), on an individual or group basis. The period for recurring loads will be defined in 
the customer account configuration. 

6.2.5.1-59 

Lead Agency representatives and customer account administrators will be able to initiate the loading of value (e.g., 
stored value and products) to customers' transit accounts individually or by group, and through a bulk process using an 
imported file in a common Agency-defined format. 

6.2.5.1-60 

The System will enable configuration of duration of short-term Passport products. 

6.2.5.1-61 

The Business Passport program will accommodate subsidies provided by employers for vanpools. These subsidies will be 
included in the billing and apportionment of Business Passport agreements. 


One transit account will be able to support at least 15 distinct fare products of the same type. Distinct fare products or 
product categories will be determined bv Agencies. 


6.2.5.1-62 
























































Capability 

Number 



6.2.5.1-64 


6.2.5.2-1 



Capability 


The configurable service day may be longer than 24 hours and service day hours may overlap. 


In the Business Choice program, organization customers may provide members with stored value E-purse and/or fare 
products._ 


The System will handle revenue apportionment according to the apportionment rules. 


The System will allocate actual revenue received from a customer using stored value E-purse among Agencies providing 
service to that customer on a per-trip basis and in proportion the value of the services provided. The value of services 
provided is calculated as the fare the customer would have paid in the absence of an intra-agency and/or inter-agency 
transfer agreement. 


The System will allocate actual revenue received from a regional monthly or day pass among Agencies providing service 
to that customer, for the duration of the pass product, in proportion to the value of services provided, which include the 
calculation of transfers. Revenue-sharing provisions will be configurable by the region. 


Calendar monthly pass products will be valid for the designated month purchased. The revenue will be available for 
distribution whether or not the product is used. 


Section 6.3 Customer Relationship Management Application 


6.3.1-1 

The SI shall deploy a CRM application that provides central management for all customer data, customer service 
operations, and fare media and product ordering and fulfillment, as well as cradle-to-grave tracking of all customer 
service contacts and requests. The CRM application will be a COTS solution, and there is a preference for a web-based 
CRM solution. 

6.3.1-2 

The core function of the CRM application will be to support call center operations with a tool that provides a 360-degree 
view of the customer, and enables creation, viewing, and modification of customer service records related to contacts 
and requests, and the actions taken to resolve those requests. 

6.3.1-3 

The CRM will have functionality that allows for the creation of incidents related to assets in the AIM. 

6.3.1- 

■ 

The CRM will support the issuance of refunds for fare media and product sales as needed and create the appropriate 
transactions in the Financial Management application (accounts payable) using the Customer Account Management API. 

6.3.1-5 

The CRM will allow customer account creation and transit account registration. 

6.3.1-6 

The Program needs the SI to deploy a CRM application that provides access to all transit and customer account 
information, and the ability to track all customer service contacts and requests, including escalation from initiation 
through resolution. 

6.3.1-7 

The CRM application will provide central order management and fulfillment functionality for the distribution of fare 
media and products sold through all fare distribution channels, including but not limited to orders placed through the 
customer website and mobile app. The CRM application will interface with the FMM to maintain proper fare media 
inventory controls. 

6.3.1-8 

Access to the CRM application will require multi-factor authentication or other Agency-approved authentication 
technology that meets the criteria outlined in NIST 800-63, and allowed functions will be restricted based on centrally 
defined user-access privileges. 

6.3.1-9 

The CRM application will be able to track and flag risky forms of payment including credit/debit cards that are on a 
system hot list, previously denied personal and corporate checks, and purchase orders linked to customer accounts with 
a poor payment history. 

6.3.1-10 

The CRM application will connect to the ATP using the Sl-provided API, and provide a fully integrated interface for 
customer service staff to view and modify customer and transit account data. 

6.3.1-11 

The CRM application will accept credit cards, debit cards, and bank account (ACH) transfers for funding during fare media 
and product sales online and the setup of autoload. 

6.3.1-12 

The CRM application will support split payments where up to three (3) funding methods, including multiple bank cards, 
can be used to complete payment for a single sale. 



Comments 


INIT would like to discuss the motivation for this requirement and come up with a solution in the 
negotiation or system design phase. Each product can have validity over the service day end. I.e. 
roduct validity is not bound to the service dav limit. 

























































Capability 

Number 


6.3.1-13 


6.3.2-1 


6.3.2-2 


6.3.2-3 


6.3.2-4 


6.3.2-5 


6.3.2-6 


6.3.2-7 


6.3.2-8 


6.3.2-9 


Capability 

The SI shall deploy a CRM application that provides the ability to email/text message customer accounts. 

Communications can be distributed based upon business rules using information in the application, for example 

autoload customers, customer account type, and product type. _ 

The CRM will maintain customer accounts that store all customer data, including all personal, contacts, members and 

payment information associated with customer accounts. _ 

The CRM application will have the ability to define and categorize customer accounts by type (e.g. individual, family, 

university, non-profit, business, corporation, elementary school). _ 

The CRM will be able to serve as the repository for all information on customers applying for a reduced fare 
classification, including applications and supporting documentation, eligibility parameters, and fare media 

personalization information, such as customer photographs. _ 

The CRM application will be supported by a customer information repository that is fully compliant with all applicable 
PCI standards and the region's ISMS control baseline at the time of Final System Acceptance, and with all agency, state, 

and local policies and regulations for the handling of Pll. _ 

Each transit account will only be associated to one (1) active piece of fare media at a time. The System will support fare 
media replacement in the event that a media is lost, stolen, or damaged, which will associate a new piece of fare media 

to an existing transit account and block use of the old fare media. _ 

The CRM will serve as the repository for all information on employees, contractors, and other organization members 
who are issued fare media by a customer account, including fare media personalization information, such as customer 

photographs. Actual repository content/structure may vary according to customer account type. _ 

The System will allow multiple transit accounts to be associated with the same customer account for consolidated transit 

account management through all customer service channels. _ 

The System will allow a customer account to be created without associating a transit account. 

Customer data maintained in a customer account will include identity and contract information at a minimum. Actual 
content will be defined during design, and made available for operations by customer account type configuration. The 
following is an initial list of generalized information that will be captured 

• Customer account type 

• Names (organizational and individual) 

• Addresses (such as Primary, Billing, and Customer Service) 

• Phone numbers 

• Texting phone numbers 

• Email addresses 

• Website/Mobile usernames/encrypted password 

• Security questions and answers 


6.3.2-10 


The CRM application will be able to capture passenger type (such as Adult, Senior, and Youth) and capture one or more 
additional classifications (such as Access eligibility). The source for this information will be determined during design. 


6.3.2-11 


6.3.2-12 


6.3.2-13 


6.3.3-1 


The Agencies will be able to use the CRM to serve as administrators for their own customer accounts and other 

organizational programs as necessary. _ 

The CRM application will allow transit account customers to be disassociated with customer accounts. 

The CRM application will support adding fare products including E-purse value to a transit account that contains a 

current or expired business product. _ 

The CRM application will support customer account programs that allow for tracking and management of business rules 
for distribution channels, fare products, and special programs. The ability to perform this function is configurable by 
customer account tvoe. 














































Capability 

Number 


Capability 


63.3-2 

Customer account program administrators will be able to associate transit accounts to their customer accounts 
individually using credentials, and through a bulk process using an imported file in an Agency-defined format. The ability 
to perform the bulk process will be configurable by customer account type. 

6.33-3 

The CRM application will allow customer accounts with appropriate privileges to remove fare products supplied by 
customer accounts from associated transit accounts and block remaining use of passes. This will be possible without the 
deletion of the transit account or removal of any E-purse value or passes purchased directly by the transit account 
holder. 


When fulfilling a bulk EU fare media order for a customer account, the System will automatically generate an import file 
pre-populated with the credentials to support the addition of customers by the customer account. The ability to perform 
this function is configurable by customer account type. 

6.33-5 

The CRM application will enable the placement of bulk orders for fare media to be delivered by the mail center. Bulk 
sales may include media where the associated transit accounts are pre-loaded with value. The ability to perform this 
function is configurable by customer account type. 

6.33-6 

Read and write permissions by the customer account administrator will be determined by preset permissions associated 
with their credentials and customer account type. 

6.33-7 

The CRM will support contracted pricing for Business Passport agreements, including both fixed and per-trip pricing. 

6.33-8 

The CRM application will enable the bulk sale and issuance of fare media, including the initialization and loading of the 
associated transit accounts, through entry of a transit account/fare media identifier range or upload of a file. 

6.33-9 

At a minimum, the following configuration parameters will be supported to govern participation in customer account 
programs: 

• Program type (e.g.. Business Choice, Passport) 

• Qualifying customer account types 

• Available fare media 

• Available fare products 

• Fare media and product pricing 

• Fare media and product ordering windows 

• Payment type (e.g., prepay or invoice) 

• Payment terms 

The customer account program configuration parameters will be set by the Agencies during registration of a customer 
account customer and will be stored in the customer account. 

6.3.3-10 

Customer account programs will include post-bill programs where the account is invoiced based on the customer's actual 
usage of the System. For these programs, the customers' transit accounts will be loaded with an unlimited-ride pass (i.e.. 
Passport), and the System will calculate the amount due on-a-monthly basis using pass ridership data and an Agency- 
defined formula. 

6.3.3-11 

The Agencies may use the CRM application to register a customer account and configure all parameters governing the 
customer account's participation. 

6.3.3-12 

All data associated with customer accounts will be stored securely and associated with the Accounts Receivable and 
Billing, CRM application and the customer website. 

6.3.3-13 

When associating transit accounts, the customer account will be able to provide fare media personalization information 
(e.g., employee name or ID) that uniquely identifies the customer in possession of the associated fare media. If 
personalization information is provided, it will be stored in the transit account and serve as a unique identifier separate 
from customer registration data, should the customer choose to register the transit account. 

6.3.3-14 

Customer account program administrators will be able to disassociate transit accounts from their customer account 
program, individually by selection and through a bulk process using an imported file in an Agency-defined format. The 
actual individual transit account will remain. 
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Capability 


The CRM application will support the management of customer account programs, which will allow transit accounts to 
be associated to a customer account (e.g., employer or school) for account management and the loading of value. 


The CRM application will support the current range of business (organizational) account programs offered by the Agency, 
and future programs, including but not limited to: 

• U-Pass and other college programs 

• School (K-12) programs 

• Corporate and employer programs 

• Government and military programs 

• Social service agency programs 

• Local attraction and tourist programs 

• Partner programs supporting transit-related services, including parking 

• Agency promotional programs 

• Residential pass programs 


The CRM application will allow customer accounts with appropriate privileges to provide a means of funding transit 
accounts that will charge the funding source only for value used by the associated transit accounts. This could be 
achieved by a customer providing a funding source to transit accounts that has a configured maximum that can be drawn 
on by each transit account, or by a method to reclaim funds that are used to pay for unused E-purse or products by a 
configurable date or time period. Customers will be able to perform this function for an individual transit account or a 
group of transit accounts._ 


The CRM application will support call center and in-person customer service operations by providing a complete view of 
the customer and related transit and customer account activity, including all activity associated with anonymous transit 
accounts. 


The CRM application will allow customer service staff, based upon security roles and customer account type, to perform 
customer account actions, including but not limited to: 

• Create new customer account 

• Assign customer account type designation to the customer account 

• View customer account status and data 

• Modify customer account data 

• Associate a transit account to a customer account 

• Disassociate a transit account from a customer account 

• Add, update and delete a funding source from a customer account 

• Close or suspend a customer account 


The CRM application will provide the capability to store all customer account correspondence related to invoicing and/or 
payments. 


The CRM application will allow Regional Reduced Fare Permits (RRFPs) for persons with disabilities to be associated with 
a transit account configured with a Personal Care Attendant (PCA) designation. PCA designation will be reflected on the 
rinted RRFP cards. 


Agency/customer service staff will have the ability to set up fare products (e.g., stored value, multi-ride products, and 
passes) for autoload, or to automatically reload based on time or value thresholds. The Program needs the SI to enable 
this functionality through the CST. CRM application, customer website, and customer mobile app. 































Capability 

Number 

Capability 

6.3.4-6 

The CRM application will enable customer service staff to perform transit account actions, including but not limited to: 

• Sell all supported fare media (and create new transit accounts) 

• Sell all supported fare products (e.g., stored value and passes) and load fare products to transit accounts 

• Query transit account status (e.g., associated passenger type, active/inactive, blocked/unblocked) 

• View fare payment transaction history 

• View sales transaction history 

• View adjustment transaction history 

• Enable fare product for autoload (requires funding source in customer account) 

• Generate fare payment reversal (e.g., cancellation) 

• Generate sales reversal 

• Generate sales refund 

• Generate an account adjustment (e.g., credit or debit) 

• Transfer balance between two transit accounts 

• Block/unblock card, account, or individual fare product 

• Replace lost, stolen, or damaged card (e.g., associate new card with existing account) 

• Generate an opt-out refund (e.g., close transit account and issue refund) 

• Capture open-ended notes (size to be determined during design) 

6.3.4-7 

The CRM application will enable the bulk registration and loading of transit accounts in support of special fare programs 
through entry of a transit account/fare media identifier range or upload of a file. 

6.3.4-8 

The CRM application will enable the bulk blocking of transit accounts and issuance of transit account adjustments 
through entry of a transit account/fare media identifier range or upload of a file. 

6.3.4-9 

The CRM application will enable the CSR to print packing slips and mailing labels. 

6.3.4-10 

The CRM application will track all customer service contacts and requests, and the actions taken to resolve those 
requests, in customer service records that can be created, viewed, and modified using the CRM tool. 

6.3.4-11 

Customer service records will be created automatically based on customer-initiated actions performed through the 
customer website and customer mobile app. 

6.3.4-12 

All actions performed by customer service staff that result in a change to a customer or transit account will automatically 
generate a customer service record. 

6.3.4-13 

Customer service staff will be able to manually create or update (e.g., add notes) a customer service record when 
responding to customer service requests in person, over the web, or by phone. 

6.3.4-14 

Customer service records will be created for actions associated with both anonymous and registered transit accounts, 
and will be indirectly associated all linked customer accounts whenever possible. 

6.3.4-15 

The CRM application will support the classification of customer service records by type and severity, using pre-defined 
selections and Agency-specific custom text fields. 

6.3.4-16 

The CRM application will allow viewing and modification of all customer account data. A request by the customer to 
reset a password will require the answering of security questions set at the time of registration. For password resets, a 
temporary password will be automatically emailed or texted to the customer. 

6.3.4-17 

The CRM Application will enable the bulk uploading of customer information using an Excel or .csv file. This can be used 
by appropriately configured customer account types and by Agency staff to load large numbers of individual customers 


I at one time. _ 

Section 6.4 Asset Incident Management application (AIM) 

|The SI will deploy an Asset Incident Management application (AIM) to support the management of all ORCA assets, 
including spares, and incidents associated with the assets. 


Fully Conforming 
NonEonforming 
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Number 

Capability 

6.4-2 

The AIM will have workflow functionality to support the addition, commissioning, testing, and retirement of assets. 
Workflow will also support the incident process and routing of incidents to the right departments and approval for 
closing. 

6.4-3 

The AIM will have security functionality to support the management of access which is configurable by user role. 

6.4-4 

The AIM will have functionality to support the configuration of assets for fields including Agency, manufacturer, asset 
type, location, owner, etc. 

6.4-5 

The AIM will have functionality to support the configuration of incident information including owner, status, origination, 
type, severity etc. 

6.4-6 

The AIM will have standard and ad hoc reporting capabilities to monitor assets and incidents. Ad hoc reports will be easy 
and intuitive to build and run. 

6.4-7 

The AIM will be accessible over the web using any commonly available browser and mobile friendly using either a native 
app or browser capability. 

6.4-8 

The AIM will have workflow functionality to support the incident process. Workflow will allow for routing of incidents to 
the right departments and review, resolve, approve, and closure process. 

6.4-9 

The AIM will use the Sl-provided API to allow remote systems (such as CRM to create customer service initiated 
incidents) to query and create incidents. 

6.4-10 

The AIM will use the Sl-provided API to integrate with the System Manager for asset information and events that create 
incidents. 

6.4-11 

The AIM will provide a user-friendly interface that can be learned quickly by end users with minimal training. 

6.4-12 

The AIM will have functionality that allows remote systems (such as the CRM) to create incidents for an asset in the AIM 
or link to the incident if it already exists. 

6.4-13 

The AIM will allow for incidents to be linked together and unlinked. 

6.4-14 

The AIM will have mapping capability to link assets to locations and incidents to locations and assets at that location. 

6.4-15 

The AIM will have functionality to support incident management that includes creation, management, resolution, 
closure, and reporting. 

6.4-16 

The AIM will have functionality to support incident categorization and prioritization. 

6.4-17 

The AIM will have functionality to support logging information and activity associated with an incident. 

6.4-18 

The AIM will provide for manual .csv or Excel upload of device inventories by the Agencies of new equipment received. 

6.4-19 

The AIM design will not preclude future integration through an API or industry standard center-to-center interface with 
the Agency enterprise asset management, maintenance, or decision support applications for static and real time device 
information. 

6.4-20 

The AIM will have fields for basic device inventory information including but not limited to device name, serial number, 
location, model, Agency owner, maintenance history, break history, device type, date in service, date out of service, etc. 
The addition of user defined fields will be possible. 

6.4-21 

The AIM will provide for manual .csv or Excel download of device inventories by the Agencies. 

6.4-22 

The AIM will have operational lookup capabilities on any of the fields or combination of fields within the application, 
including device, owner, alert type, devices type, location, etc. 

6.4-23 

The AIM will provide a tool to perform ad hoc reporting and build configured reports available to end users. 


6.4-23 


Fully Conforming 
NonEonforming 
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Number 



Capability 


The AIM application will provide the "next number" to issue when adding new assets to the inventory. 







Comments 


This is generally not possible in a multi-client environment as providing the next number would also 
imply reserving/locking the number or number range (batch import) for a certain client. We are 
however sure that there is another solution to the issue that caused this requirement to be added to 
X the RFP. 

We would be interested on discussing the motivation behind this "next number" requirement ad find 
a solution for it. 


Section 6.5 System Manager 


The System Manager will monitor and display in real-time the status of all back office systems, subsystems, applications, 
databases, and processes. Details of which processes will be monitored will be provided during design review. X 


The System Manager will have functionality that allows for the creation of incidents associated with certain events 
related to assets in the AIM. 


The System Manager will automatically monitor asset status, record asset problems and failures, notify selected staff and 
initiate aDoroDriate action. 


All equipment will be remotely monitored, configured, and managed through the System Manager using the Sl-delivered 
API. 


The System Manager will have user security to allow different roles with different levels of access. 


The System Manager will have the means to provide for a controlled shutdown of a device or system component and 
create a maintenance event. 


The System Manager will monitor the operational status and performance of the devices and their components, 
including but not limited to: 

• Onboard and wayside validators 

• Mobile access routers 

• Driver displays units X 

• Vending machines 

• Customer service terminals 

• Mobile validation and inspection devices 


System Manager queries will include tables and graphical charts showing the current and historical performance of each 
device under measurement. Queries will include but not be limited to device type. Agency, location, and individual 
device. 


The SI shall deploy a System Manager that enables the central monitoring and management of all next gen ORCA system 
devices. 


Equipment software and configuration updates, including all valid and invalid card lists, will be managed through the 
System Manager application. 


The System Manager dashboard will include a system map that can be drilled-down into by location or Agency to view 
and control that status of system components. The System map will be dynamically updated when devices or systems 
are added and removed, and configurable to allow editing of device groups, locations, and location names as the System 
expands. 


The System Manager will include a web-based interface that provides access to all monitoring and management 
functions, and provides all information in a clear, organized dashboard using color graphics and text as approved during 
the System design. 


The System Manager will provide integration to the electronic monitoring and fault detection systems associated with 
devices. 


The System Manager will have the means to detect failure of any device (including cooling device) and provide for a 
controlled shutdown of the System components and generation of a maintenance event. 
















































Capability 

Number 


6.5-15 


6.5-16 


6.5-17 


6.5-18 


6.5-19 


6.5-20 


6.5-21 


6.5-22 


6.5-23 


6.5-24 


6.5-25 


6.5-26 


6.5-27 


6.6-1 


6.6-2 


6.6-3 


6.6-4 


Capability 

Device status reported by the System Manager will include operational status (e.g., in service, degraded mode, out of 
service, or no communications), maintenance alarms associated with individual device modules, and revenue alerts (e.g., 

vault almost full/full and low stock/out of stock), as described in the equipment sections of this SOW. _ 

Events will be configurable with different severity and actions based upon severity. 

The System Manager will have the ability to monitor devices trying to connect to the next gen ORCA system that are not 

in the inventory list ("rogue" devices). _ 

For each alarm event, a corresponding event to clear the alarm will be transmitted by the VM as soon as the alarm 
condition is no longer present. Alarm conditions may be cleared either automatically by the VM or manually by service 

staff. _ 

Processor load, memory utilization, errors, and other system performance indicators will be available in real-time to help 
prevent performance degradation and troubleshoot back office issues. Alarm types and thresholds will be able to be 

configured to allow for custom alerts. _ 

Field devices or systems that are not reporting status for any reason will be easily identifiable in the System Manager, 
and the last known status and history will be available as approved during system design and accepted during user 

testing. _ 

The System Manager will display device attributes, including but not limited to device type, device ID, location, status, 

events, and alarms. _ 

The System Manager will provide real-time performance and status monitoring for all devices, back office applications, 

and network nodes using the Sl-provided System Management API. _ 

The System Manager will support the real-time issuance of device commands, and device configuration, using the Sl- 

provided System Management API. _ 

The System Manager will support the issuance of device commands system-wide and by device type. Agency, location, 

and individual device. _ 

Command sets will vary by device, but will include configuration, maintenance, revenue, and customer service functions, 

as described in the equipment sections of this SOW. Commands will be defined during design review. _ 

System Manager commands will utilize an appropriate command protocol based on industry standards, such as SNMP3, 
or a modern functional equivalent. The protocol chosen will be supported by all devices and systems, and take into 

account expected network traffic and potential for intermittent communications. _ 

The System Manager will support the setting and distribution of all configuration parameters stored locally at the 

devices, including positive and negative lists, as described in the System specifications. _ 

Section 6.6 Fare Media Management Application 

The SI shall deploy a Fare Media Management application (FMM) that maintains a full inventory of all fare media 

procured and issued by the Agencies. _ 

The FMM will maintain an inventory of all serialized Agency-issued fare media (e.g., EU media) as it is held by the 

Agencies, regional partners, and third-party distributors, and eventually issued to customers. _ 

The FMM will track the current and historical status of all media in inventory. Whenever a transaction causes a change in 
media status, the FMM will update all records accordingly. A history of all updates will be maintained to provide an audit 

trail. _ 

The FMM will maintain the item number and type of inventory at all locations (including consignment locations) at all 

times. Tracking will include type of inventory, ID numbers, and counts at each location. _ 

The System will have the ability to record all sales at each location by type of inventory, type of sale (e.g., cash, credit, or 
check), identifying inventory number of each sale item, amount of sale, date, customer account and other applicable 
data._ 


6.6-5 


Fully Conforming 
NonEonforming 
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Capability 

Number 

Capability 

6.6-6 

The fare media inventory data maintained within the FMM will include at a minimum: 

• Media serial number 

• Media type 

• Media status 

• Transit account status 

• Expiration date 

• Batch ID 

• Order ID 

• Location 

• Ship date 

Final data fields used for inventory management purposes will be determined during design review. 

n 

The FMM will support the bulk issuance of EU fare media by identifying appropriate batch IDs and serial number ranges 
to fulfill orders placed by regional distribution partners, and through the AR/Billing Module/CRM/customer website. 

6.6-8 

The System will be able to issue EU fare media associated with transit accounts with preloaded fare product in bulk for 
special promotions. 

Section 6.7 Financial Management Application 

6.7.1-1 

The System will have the ability to allow online inquiry of balances (MTD, YTD) or for any timespan. 

6.7.1-2 

The System will have the ability to support suspense account utilization with a user entered reference code for analysis 
and account tracking. 

6.7.1-3 

The System will have the ability to require each journal entry to have a unique number by type of journal. 

mssm 

The System will have the ability to support standard calendar or fiscal year of 12 periods or 13 periods as defined by the 
user. The System will have the ability to establish 13 or more accounting periods in a single fiscal year. 

6.7.1-5 

The System will have the ability to assign general authorization journal processing and rules by account code, amount, 
company, and user. 

6.7.1-6 

The System will have the ability to support calendar or fiscal business year accounting. 

mm 

The System will have the ability to allow authorized users to make additions and changes to the GL accounts without 
program or system changes. 

6.7.1-8 

The System will provide the ability to capture the following accounting line item detail on all documents: line item 
number, line item amount, and line item accounting classification information. 

6.7.1-9 

The System will have the ability to generate error reports for any data failing validation. 

6.7.1-10 

As part of design review, the SI shall be responsible for mapping each transaction type generated by the System to the 
appropriate GL entries to support automated categorization and summarization by the System. 

6.7.1-11 

The System will have the ability to provide a mechanism to correct out-of-balance conditions. 

6.7.1-12 

The System will have the ability to save a transaction prior to posting and to continue processing the transaction at a 
later date. The System will make sure that journal entries are balanced before final posting to the GL. The System will 
allow saving of incomplete and unbalanced journals; however, posting can only occur when journal is valid and balanced. 

6.7.1-13 

The System will have the ability to prevent transactions from posting to GL accounts that have been de-activated. 

6.7.1-14 

The System will have the ability to prevent transactions from posting that would cause GL debits and credits to be out-of- 
balance at any level of the organization's accounting classification structure specified on a transaction. 

6.7.1-15 

The System will have the ability to allow real time validation of all transaction related data coming from integrated 
systems against the GL tables (e.g., account. Agency, active/inactive date) and create exception reports for all 
transactions. 

6.7.1-16 

The System will have the ability to allow an authorized user to reprint a journal entry. 


6.7.1-16 


Fully Conforming 
NonEonforming 






























































Capability 

Number 

Capability 

6.7.1-17 

The System will have the ability to support user-defined accounting periods. 

6.7.1-18 

The System will have ability to generate next account for chart of accounts additions. 

6.7.1-19 

The System will have ability to inactivate accounts within chart of accounts, while maintaining archive status and ability 
to retrieve, review, and/or reactivate. 

6.7.1-20 

The System will have the functionality to create and maintain allocations. Allocations will be configurable using any 
financial account or statistical account in the Financial Management application, formulas, prior periods/years, multiple 
input/output sources, effective dates, account ranges, accounting period and existing balances to create the pools and 
targets of allocation. Allocations can be single and multi-step with no limit to the number of allocations. The Financial 
Management application will automatically create the journal entries for each allocation referencing the date and 
allocation name with a full transaction trail in each transit account impacted. 

6.7.1-21 

The System will have the ability to identify which ledger to post journal entries through configuration rules. 

6.7.1-22 

The System will have the ability to make sure that total debits equal total credits for a single journal entry (e.g., double¬ 
entry accounting). 

6.7.1-23 

The System will have the ability to accept and post only balanced journal entry transactions (debits equal credits). 

6.7.1-24 

The System will have the ability to view date, amount, account name, account number, user ID, user name, and 
description when processing journal transactions. 

6.7.1-25 

The System will have the ability to provide full audit trail of allocations. 

6.7.1-26 

The System will have the ability to download results of allocations and reports to Excel for further analysis. 

6.7.1-27 

The System will have the ability to track source information during journal transaction processing. 

6.7.1-28 

The System will have the ability to display in real time running totals when inputting debit and credit journal entries. 

6.7.1-29 

The System will have the ability to create journal entries for current period, any future periods and prior periods subject 
to user access limits. 

6.7.1-30 

The System will have the ability to copy description and accounting from a previous line to the next line. 

6.7.1-31 

The System will have the ability to capture user defined attributes including journal category, journal source, create by 
user, create date, updated by user, update date, etc. 

6.7.1-32 

The System will have the ability to capture description at header level and line level. 

6.7.1-33 

The System will have the ability to batch, edit, post, and search journal entries in real time. 

6.7.1-34 

The System will have the ability to auto generate offsetting accounting entries based on user defined business rules. 

6.7.1-35 

The System will have the ability to allow the creation of templates for standard journals. 

6.7.1-36 

The System will have the ability to add multiple lines to a journal entry. 

6.7.1-37 

The System will have the ability to search Chart of Accounts (COA) by code or description. 

6.7.1-38 

The System will provide the ability to generate recurring entries in future accounting periods. 

6.7.1-39 

The System will have the ability to create multiple charts of accounts -- global, local statutory, and consolidation for all 
divisions and Agencies. 

6.7.1-40 

The System will have the ability to use a chart of accounts consistent with the basic numbering structure provided by the 
FTA and allow for expansion of accounts segments. 

6.7.1-41 

System will have ability to accept automated recording of journal entries directly from subsidiary ledgers. 

6.7.1-42 

The System will have the ability to automatically number journal entries. 

6.7.1-43 

The System will have the ability to enter statistical journal entries for posting data such as head count, square feet, 
ridership and/or unit volumes or fixed percent rates to be used in allocations or reporting. 


Fully Conforming 
NonEonforming 
















































































Capability 

Number 

Capability 

6.7.1-44 

The System will have the ability to perform auto generation of serial number and batch number for the journal entry. 

6.7.1-45 

The System will have the ability to validate that the total amount of the batch transactions is equal to the batch header 
total. The System will allow for automatic validation rather than manual. 

6.7.1-46 

The System will have a financial data architecture that allows for elements to code transactions. These include financial 
accounts, products. Agency, sales channel, department and at least two additional configurable elements. The elements 
will be available in the GL and all subsidiary ledgers and modules for use in coding and reporting. 

6.7.1-47 

The System will perform the revenue distribution based upon calculations from the ATP and provide the necessary 
reporting to enable the settlement of funds. 

6.7.1-48 

The System will be implemented using a COTS, SaaS if possible, enterprise-level financial management software that 
interfaces with Sl-designed software modules as necessary to provide the required functionality. 

6.7.1-49 

The Program needs the SI to employ an expert with the accounting and technical knowledge necessary to fully setup and 
configure the Financial Management application based on accounting best practices and the specific design of the 
delivered system. 

6.7.1-50 

The System will have the ability to perform allocations by any data within the Financial Management application (e.g., 
account, department, Agency) including statistical accounts. 

6.7.1-51 

The System will have the ability to define workflow rules for journal approval routing based on amount or other criteria. 

6.7.1-52 

The System will have the ability to allow users to decide whether changes will update real-time or in batch. 

6.7.1-53 

The System will have the ability to use standardized rules (e.g., GL posting rules, edits, etc.) identified by reference codes 
to control transaction editing and posting to the appropriate GL account, and updating other information maintained. 

6.7.1-54 

The System will have the ability to validate all accounts again during posting. 

6.7.1-55 

The System will have the ability to validate accounts in all input transactions, including online entries, spreadsheet 
uploads and interfaces. The System will validate all portions of the account key. 

6.7.1-56 

The System will have the ability to change error handling default (i.e., error recycle or suspense) at the journal entry 
level. 

6.7.1-57 

The System will have the ability to assign responsibility and ownership of accounts for reconciliation. 

6.7.1-58 

The System will have the ability to allow authorized users to correct out-of-balance conditions discovered during the 
reconciliation process. The System will maintain an audit trail of any such corrections. 

6.7.1-59 

The System will provide the ability to automatically post to GL weekly or more frequently if needed. 

6.7.1-60 

The System will perform integrity checks on batches received via interfaces. Checks will include a batch number and 
amount, and make sure amounts in header agree with records in the batch. 

6.7.1-61 

The System will have the ability to allow establishment of permanent (balance sheet) accounts in GL that can only be 
updated by subsidiary systems with allowance for authorized override. 

6.7.1-62 

The System will provide the ability to restrict the accounting date to open periods. 

6.7.1-63 

The System will have the ability to suspend a batch if a journal entry transaction is not balanced. 

6.7.1-64 

The System will have the ability to restrict, based on security level, who can change error handling defaults on journals. 

6.7.1-65 

The System will have the ability to reprocess suspended journal for posting. 

6.7.1-66 

The System will have the ability to reject journals in error, correct errors online, and reprocess journal for posting. 

6.7.1-67 

The System will have the ability to allow an authorized user to delete an unposted journal entry. 

6.7.1-68 

The System will have the ability to allow an authorized user to copy journals. 


Fully Conforming 
NonEonforming 







































































Capability 

Number 

6.7.1- 69 

6.7.1- 70 

6.7.1- 71 

6.7.1- 72 

6.7.1- 73 

6.7.1- 74 

6.7.1- 75 

6.7.1- 76 

6.7.1- 77 

6.7.1- 78 

6.7.1- 79 

6.7.1- 80 

6.7.1- 81 

6.7.1- 82 

6.7.1- 83 

6.7.1- 84 

6.7.1- 85 

6.7.1- 86 

6.7.1- 87 

6.7.1- 88 

6.7.1- 89 

6.7.1- 90 

6.7.1- 91 

6.7.1- 92 

6.7.1- 93 

6.7.1- 94 

6.7.1- 95 

6.7.1- 96 

6.7.1- 97 

6.7.1- 98 


Capability 

Fully Conforming 

NonHonforming 

The System will have the ability to view online whether or not a journal is reversing as well as if the transaction line is 
reversing. 

111 

The System will have the ability to restrict posting unapproved journals. 

D 


The System will have the ability to create a future dated journal to closed periods. 



The System will have the ability to edit all entered, but not posted journals. 

D 


The System will have the ability to conduct journal entry and posting in separate stages. 

D 


The System will have the ability to capture processing date together with effective date of journal entry. 



The System will have the ability to rollup expenses for the same cost center/Agency across business units. 

D 


The System will have the ability to apply allocations to both actual and budget fields. 



The System will have ability to review journal entries in workflow and approve them prior to entry into GL. 

D 


The System will have the ability to capture comments on transactions at the lowest level (i.e., comments can be both 
text and attachments). 


The System will have the ability to define skeleton journals where the amounts change monthly, but the accounts remain 
the same. 


The System will have the ability to drill down (e.g., to descriptions, from journal to source activity). 

D 


The System will have the ability to enter a journal entry without authority for posting it. 

D 


The System will have the ability to enter and maintain statistical information either along with or independently of 
journal entries. 

mi 

The System will have the ability to provide a free-form notes section to attach to a journal entry or transaction. 

m 


The System will have the ability to create and approve journals. 



The System will have the ability to reverse a posted journal entry manually or systematically. 

D 


The System will have the ability to schedule automated, integrated, and recurring journals to run and post without user 
intervention. 

nil 

The System will have the ability to view or print journals online in a summary or detail format. 

D 


The System will provide the ability to capture start dates, end dates, and posting frequency for recurring entries. 

D 


The System will provide the ability to capture the date a transaction is effective in the GL (i.e., the date a financial event 
is recognized). 

on 

The System will provide the ability to generate and modify online reversing entries in future accounting periods. 

D 


The System will include a user access management tool that will control and configure user access privileges to each 
module or component of the entire system. 


The System will support business rules and procedures that provide fast and efficient month end close processing 
including workflow for approvals and messaging, and subsystem posting. 


The System will have the ability to reopen the final accounting period to post audit adjustments. 

O 


The System will have the ability to allow authorized users to define general ledger posting rules and the logic associated 
with each transaction. 


The System will provide a method to create transaction corrections in a manner that allows subsystems to update the GL 
keeping it in sync. 


The System will provide the ability to process year-end adjustments. 

D 


The System will have the capability to carry forward into the new fiscal year GL account balances and updates for current 
activity prior to the final year-end closing. 


The System will have the ability to allow authorized end users to add/change/delete business logic, based upon design 
and testing, within Chart of Account and report hierarchies. 





















































































Capability 

Number 


Capability 

The System will support the full auditing of all system financial activity, including reconciliation of all Agency revenue and 
customer accounts, and end-to-end tracking of revenue as it is generated and recognized by the participating Agencies. 


6.7.1- 99 

6.7.1- 100 

6.7.1- 101 

6.7.1- 102 

6.7.1- 103 

6.7.1- 104 

6.7.1- 105 

6.7.1- 106 

6.7.1- 107 

6.7.1- 108 

6.7.1- 109 

6.7.1- 110 

6.7.1- 111 

6.7.1- 112 

6.7.1- 113 

6.7.1- 114 

6.7.1- 115 

6.7.1- 116 

6.7.1- 117 

6.7.1- 118 

6.7.1- 119 

6.7.1- 120 

6.7.1- 121 

6.7.1- 122 

6.7.1- 123 

6.7.1- 124 

6.7.1- 125 


The System will support daily cash settlement to Agency bank accounts. 

The Agencies will have the capability to generate manual GL postings to support corrections and the tracking of activity 

that is not performed by the System. _ 

Summary entries will be posted to the GL automatically at the end of each closeout period, no less than daily. 

The System will support the reconciliation of the stored value deferred revenue GL account balance to the total transit 

account balances maintained within the ATP at any point in time. _ 

The System will provide support for current and future standard banking formats such as SWIFT and BAI. 

The System will provide interfaces or related files to support banking capabilities such as positive pay and monthly 

reconciliation for checks issued. _ 

The System will have the capability to reconcile checks/wire transfers. 

The System will have the capability to produce a file containing all rejected check reconciliation transactions which could 

be available for corrections. _ 

The System will have the capability to identify un-reconciled customer account check payments online and from reports. 

The System will have the capability to determine online if a customer account check has cleared at the bank based upon 

reconciliation data. _ 

The System will have the capability to allow for automatic bank reconciliation via bank interface of bank cleared funds, 

direct debits, receipts compared to system payment records. _ 

The System will provide the capability to define unlimited number of banks and unlimited bank accounts for each bank 

and capability to pay from different banks. _ 

The System will provide the ability to assign a transaction number. 

The System will have the ability to trace back from allocated to original source of the cost. 

The System will have the ability to support Excel spreadsheet upload and download of journals. 

The System will have the ability to capture descriptive information on journals. 

The System will have the ability to maintain an audit trail from the original postings to the final posting when the 

accounting structure is modified. _ 

The System will have the ability to automatically reclassify accounting data when a reorganization of the classification 
structure is necessary, such that manual reversals of previously recorded detailed transaction activity is not needed. 

The System will have the ability to auto-generate a new chart of account combination if it meets the segment 

combination validation rules defined. _ 

The System will provide the ability to automatically close the subledgers on scheduled dates. 

The System will have the ability to rollover GL account balances after closing. (Note that this includes sub-accounts.) 

The System will have the ability to perform automated month-end closing of GL accounts, with approval. 

The System will have the ability to close subsystems on a different schedule from GL. 

The System will have the ability to allow selected transactions for closing, e.g., adjustments, to be processed. 

The System will have the ability to re-open prior periods and make adjusting financial entries; re-run allocations using 

the appropriate allocation methodology which may not be the current month's methodology. _ 

The System will have the ability to open/close prior closed periods multiple times based on business rules (not externally 
reported). 


Fully Conforming 
NonEonforming 












































































Capability 

Number 

Capability 

6.7.1-126 

The System will have the ability to support at year-end close that all entries are in balance and that all periods have been 
closed. 

6.7.1-127 

The System will have the ability to close accounting periods and prevent the posting of new transactions to any closed 
period. 

6.7.1-128 

The System will process transactions originating in other systems, recording and keeping track of such transactions and 
related information, in order to provide the basis for central financial control. 

6.7.1-129 

The System will support the management of monthly and annual accruals. Include automated accruals to the general 
ledger, ability to enter accrual journal and automatically post reversal in future period and ability to link the accrual to 
the reversal. 

6.7.1-130 

The System will have the ability to set up standard journal entries with multiple line items and debits and credits lines 
may be uneven. 

6." 

.2-1 

The Accounts Receivable (AR) module will provide the capability to allow invoices to contain pertinent information (e.g. 
date of invoice, date of delivery, due date,) that will be defined and approved during design. 

6.‘ 

.2-2 

The AR module will have capability to update GL accounts for all accounts receivables, sales, receipts, and other 
adjustments originating in the subsidiary ledger. 

6.' 

.2-3 

The AR module will be fully installed and configured by the SI, and will support the creation and management of 
receivables and customer accounts with integration to the GL. 

6." 

m 

The AR module will provide capability that allows default customer account data such as terms to automatically populate 
when invoices are being entered. Default data will be configured according to the customer account type. 

6." 

.2-5 

Data available for a customer account will include at a minimum: 

• Customer account name 

• Administrator name 

• Multi addresses (mailing, shipping, billing, etc.) 

• Phone numbers 

• E-mail addresses 

• Special Instructions 

• Contract account agreements 

• fmtnmpr arrnunt ID 

6.' 

.2-6 

Payment terms for customer accounts will be configured as part of the account setup. The Agencies will be able to 
configure customer accounts such that payment is required at the time an order is placed, or to allow the customer 
account to be invoiced based on established payment terms. 

6.7.2-7 

The AR module will provide functionality to manage multiple payment terms of the course of a contract with customer 

accounts. 

6.' 

.2-8 

The AR module will allow customer accounts to be assigned to a specific Agency and allow for customer accounts to be 
managed by the Agency. 

6." 

.2-9 

The AR module will provide the capability for Agencies to configure custom business rules and terms for their customer 

accounts. 

6.7.2-10 

The AR module will have the capability to differentiate customer account sales and inventory sold by cash, credit card, 
check, and ACH as well as totals. 

6.7.2-11 

The AR Billing module will have the capability to capture multiple contacts for every customer account. 

6.7.2-12 

The AR module will support the aging of receivables and an automated, fully auditable write-off process to be defined 
during design review. 

6.7.2-13 

For customer account orders where invoicing is configured, an invoice will automatically be generated in the AR module, 
available for display on the customer website, and sent electronically. 

6.7.2-14 

For customer accounts where prepayment is required, the customer will be required to provide a funding source in the 
form of a credit card, debit card, or bank account (e.g., ACFI). Funding source information will be stored securely within 
the CRM in a tokenized form. 


Fully Conforming 
NonEonforming 




























































Capability 

Number 

Capability 

Fully Conforming 

NonHonforming 

6.7.2-15 

The AR module will have the capability to post credits to customer accounts. 

D 

6.7.2-16 

The AR module will support the automatic generation of invoices and monthly statements detailing account activity, 
including consolidation of multiple AR accounts on a single customer account statement. 


6.7.2-17 

The AR module will have the ability to calculate amount of invoice based on products sold, ridership use or contractual 
agreement. 


6.7.2-18 

The AR module will have ability to calculate amount of invoice utilizing customized pricing. 


6.7.2-19 

The AR module will provide the ability to include invoice transaction details such as any applicable surcharges, discounts, 
extended price, penalties, price, product/service code, volume, Agency, and mode. 


6.7.2-20 

The AR module will provide the ability to include advances and prior collections received on invoices. 


6.7.2-21 

The AR module will provide the ability to track original invoice amounts and remaining balance after receiving partial 
payments. 

D 

6.7.2-22 

The AR module will provide the ability to allow for invoices to be canceled, deleted, or voided. 


6.7.2-23 

The AR module will provide the ability to allow historical data to be viewed online for amounts invoiced, amounts paid, 
credit memos, debit memos, adjustments, and tolerance written off. 


6.7.2-24 

The AR module will provide the ability to automatically print copies of previously issued invoices at any time without 
recalculation or regeneration. 


6.7.2-25 

The AR module will provide the ability to print current and cumulative invoice totals on the same page within the 
specified invoice template. 


6.7.2-26 

The AR module will provide the ability to define different invoice formats for different types of invoices or different 
Agencies. 


6.7.2-27 

The AR module will provide the ability to print free-form recurring text on each invoice page. 


6.7.2-28 

The AR module will provide the ability to customize the text and data elements to be displayed on system-generated 
invoices, by customer type, receivable type, or billing method. 


6.7.2-29 

The AR module will provide the ability to define reason codes and related descriptions for invoice processing actions 
such as invoice adjusted, invoice held for payment schedule, and invoice canceled. 


6.7.2-30 

The AR module will provide the ability to derive the invoice date from the System date. 


6.7.2-31 

The AR module will provide the capability to support a system link to trace voided (original) invoice to the revised 
invoice. 


6.7.2-32 

The AR module will provide the ability to store a complete copy of the contract with online review and print capability. 


6.7.2-33 

The AR module will not reuse voided invoice numbers. 


6.7.2-34 

The AR module will provide the capability to allow default customer account data such as name to automatically 
populate when invoices are being entered. 


6.7.2-35 

The AR module will provide capability that allows customer data such as customer account number to automatically 
populate when invoices are being entered. 


6.7.2-36 

The AR module will provide capability for comments to be entered against an invoice. 


6.7.2-37 

The AR module will have the capability to capture unlimited document line items per invoice. 


6.7.2-38 

The AR module will provide the capability to update the invoice date on each record. 


6.7.2-39 

The AR module will provide the capability to store journal ID, user, paid date, posted date, transaction amount, 
transaction ID, transaction type, etc. for all invoice transactions. 


6.7.2-40 

The AR module will provide the capability to produce invoices to any customer account for NSF checks received. 


6.7.2-41 

The AR module will have an option to generate a receipt for customer account payments. 


6.7.2-42 

The AR module will have the capability to record cash receipts and apply to a GL account. 


6.7.2-43 

The AR module will provide the capability to reconcile any payments to the appropriate invoice. 

D 


Comments 
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6.7.2-44 

The AR module will support the capability to record billing items (e.g., fare media and products) by line item in order to 
identify unique accounting classification codes. 

6.7.2-45 

The AR module will support the setting of configurable credit limits for customer accounts. The AR module will support 
the automated generation of credit holds, and disabling of order privileges within the customer website, when the credit 
limit is reached. 

6.7.2-46 

The AR module will support the application of payments (full and partial), credit memos, and adjustments against 
customer accounts. The process will support batch entry of receipts and lockbox functionality. The AR module will 
provide the capability to apply partial payments against an invoice and the ability to apply one payment to multiple 
invoices. 

6.7.2-47 

The AR module will provide the capability to track and post refunds to a customer account against the applicable 
contract and/or invoice. 

6.7.2-48 

The AR module will provide the capability to track check number, payment reference (for electronic payments), check 
date, check amount, contract number, account name, address, point of contact name when duplicate payment returned 
to issuing customer account. 

6.7.2-49 

The AR module will provide tracking and collection processes for open accounts receivable. 

6.7.2-50 

The AR module will provide the capability to store a copy of demand letter for payment. 

6.7.2-51 

The AR module will have the option of sending a form letter along with any statement either electronically or physically. 

6.7.2-52 

The AR module will provide automated write-offs capability based on user defined criteria. 

6.7.2-53 

The System will have the capability to generate statements on request, categorized by month, displaying history, invoice 
number and date, check number received and amount, customer, and amount due. 

6.7.2-54 

The AR module will support the automatic generation of interest charges for charges that are past due, and generate 
dunning (e.g., collection) letters for overdue receivables when they become delinquent. 

6.7.2-55 

Accounts Receivable and Billing reports will be created and used to make manual entries in the participating Agencies' 
financial applications. All reports can be exported to .csv or excel and can include invoice amounts, customer account 
name, amounts paid, outstanding balances and other information in The AR module. 

6.7.2-56 

The AR module will track receivables for prepaid, post-bill fare media and product sales initiated through the CRM 
application and customer website to support bulk sales and special fare programs. 

6.7.2-57 

The AR module will provide the capability to perform online queries of account activity (e.g., billing, collection, and 
adjustment) by customer account and receivable to support the display of invoice, account, and payment status in the 
CRM application and on the customer website. 

6.7.3-1 

The Accounts Payable (AP) module will support the issuance of customer account refunds via check or wire transfer 
depending on transaction amounts. 

6.7.3-2 

The AP module will prohibit a vendor from having more than one Vendor ID in the System. The System will also provide 
the ability to define parent/child/partner/other relationship fields/categories to facilitate vendor-based reporting. 

6.7.3-3 

The AP module will provide the ability to process refunds from Accounts Payable or CRM. The Customer Account 
Management API will provide integration with the Financial management application through Accounts Payable for the 
issuance of customer account refunds. 

B 

The AP module will have the ability to create vendors and maintain the necessary information for correspondence, 
payment and 1099 tracking (e.g., name, address, contract, payment terms, payment method, tax ID). 

6.7.3-5 

The AP module will allow assigning payment method (check, ACH, wire transfer, etc.) to the vendor and only authorized 
users can make changes. 

6.7.3-6 

The AP module will provide the ability to default vendor payment terms and capture payment terms on an invoice that 
are different than those specified on the associated vendor record. 

6.7.3-7 

The AP module will have the ability to produce letters for vendors who have not yet provided a tax id. 
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6.7.3-8 

The AP module will provide the ability to update payment status after confirmation from bank interface. 

D 


6.7.3-9 

The AP module will provide the ability to access vendor list when processing invoices. 



6.7.3-10 

The AP module will provide fields to differentiate the invoice date from the received date for vouchers. 

□ 


6.7.3-11 

The AP module will provide the ability to do paperless matching between invoice, purchase order and/or receipt. 

D 


6.7.3-12 

The AP module will provide the ability to void a payment and reissue without rekeying the invoice. 

D 


6.7.3-13 

The AP module will provide the ability to either withhold, transfer, or release retainage and costs. 

D 


6.7.3-14 

The AP module will provide the ability to enter comments while processing invoices. 

D 


6.7.3-15 

The AP module will provide the ability to enter invoices and code them to specific projects, departments, or Agency. 

Dll 

6.7.3-16 

The AP module will provide the ability to establish funding schedules for each bank account. 

D 


6.7.3-17 

The AP module will provide the ability to link bank wire number to invoice number. 

D 


6.7.3-18 

The AP module will provide the ability to make accounting adjustments to invoice after posting but before payment. 


6.7.3-19 

The AP module will provide the ability to record internal comments on invoices that will not appear on the check 
remittance advice and the ability to record external comments that will appear on the check remittance advice. 


6.7.3-20 

The AP module will provide the ability to categorize invoice types. 

D 


6.7.3-21 

The AP module will provide the ability to default accounting fields for payments. 

D 


6.7.3-22 

The System will provide the capability to create a positive pay file for the bank. 

D 


6.7.3-23 

The AP module will support partial payments to vendors. 

D 


6.7.3-24 

The AP module will provide the ability for vendors to participate as an ACH payee. 

D 



Payment will be considered to be made on the settlement date for an EFT payment or the date of the check for a check 



6.7.3-25 

payment. Payments falling due on a weekend or federal holiday may be on the following business day without incurring 
late payment interest penalties. 

X 


6.7.3-26 

The AP module will provide the ability to identify payments to be disbursed in a particular payment cycle based on their 
due date. 


6.7.3-27 

The AP module will provide the ability to record payments made on behalf of another Agency, citing the other Agency. 


6.7.3-28 

The AP module will provide the ability to void payments and reverse invoices. 

m 


6.7.3-29 

The AP module will provide the ability to modify recurring payments schedules. 

D 


6.7.3-30 

The AP module will have the ability to link a copy of a check to a corresponding invoice. 

m 


6.7.3-31 

The AP module will provide the ability to allow check remittance advice prints with the check. 

D 


6.7.3-32 

The AP module will provide the ability to allow processing of prepayments (advances) and applying prepayments to 
invoices once invoices are received. 


6.7.3-33 

The AP module will provide the ability to prevent the creation of EFT (Fedwire, ACH, or CTX) funding that does not 
contain a RTN, bank account number and account type (checking or savings). 


6.7.3-34 

The AP module will provide the ability to process debit/credit memos. 

D 


6.7.3-35 

The AP module will provide the ability for the starting payment number to be entered when printing checks. 



6.7.3-36 

The AP module will provide the ability to pay from multiple bank accounts. 



6.7.3-37 

The AP module will provide the ability to pay invoices individually (one check per invoice). 



6.7.3-38 

The AP module will have the ability to show both pending and released payments. 

□ 


6.7.3-39 

The AP module will provide the ability to perform multiple check runs in a given day. 



6.7.3-40 

The AP module will provide the ability to prevent payment to vendors with a debit balance (AR/AP netting). 

D 



Comments 
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6.7.3-41 

The AP module will be able to attach supporting documentation, such as receiving documents and correspondence 
relating to the invoice. 

6.7.3-42 

The AP module will provide the ability to assign unique application-generated document numbers to invoices along with 
the vendor invoice number. 

6.7.3-43 

The AP module will provide the ability to scan and store invoice documents. 

6.7.3-44 

The AP module will provide the ability to automatically create invoice and line detail from a corresponding purchase 
order/receipt. 

6.7.3-45 

The AP module will provide the ability to allow for user-defined treatment of matching differences to include: payment 
hold, payment with debit memo, or payment after workflow routing for proper authorization. 

6.7.3-46 

The AP module will provide the ability to allow partial approval of invoices. 

6.7.3-47 

The AP module will provide the ability to assign invoices to individuals for approval. 

6.7.3-48 

The AP module will provide the ability to enable workflow for approval routing of invoices and vendors. 

6.7.3-49 

The AP module will provide the ability to identify and resolve matching exceptions. 

6.7.3-50 

The AP module will provide the ability to include reason codes and a comment field on invoices that are not approved. 

6.7.3-51 

The AP module will provide the ability to apply credit memos to existing invoices or on the vendor's account. 

6.7.3-52 

The AP module will provide the ability to specify multiple approvers with business rules within workflow. 

6.7.3-53 

The AP module will provide the ability to apply the credit to any transit account specified regardless of the actual 
disbursement against which the credit may be applied. 

6.7.3-54 

The AP module will provide the ability to process future dated invoices. 

6.7.3-55 

The Financial Management application will provide the ability to use multiple inter-company accounts for accounts 
payable purposes 

6.7.3-56 

The AP module will provide the ability to calculate discounts based upon invoice date. 

6.7.3-57 

The AP module will provide the ability to calculate multiple due dates when items on an invoice have different payment 

terms. 

6.7.3-58 

The AP module will provide the ability to notify vendors of payments that have been offset by credit memos. Specifying 
the invoice number, invoice amount, payment amount, and payment date. 

6.7.3-59 

The AP module will provide the ability to split invoice lines between 1099 and non-1099 lines. 

6.7.3-60 

The AP module will provide the ability to prevent payments without corresponding invoices. 

6.7.3-61 

The AP module will provide real-time visibility of vendor payment status to authorized users. 

6.7.3-62 

The AP module will provide the ability to view outstanding vendor balances. 

6.7.3-63 

The AP module will have the ability to retain cleared checks in a database for inquiry and/or reporting purposes. 

6.7.3-64 

The AP module will have the ability to perform online query to provide payment information via accounts payable 
transactions by an invoice number. 


The System will have the ability to allow users access to historical general ledger entries and be able to sort them by 
financial data architecture elements (e.g., account, department, product. Agency). 


The Financial Reporting and Query Module will have functionality to run custom queries and provide a dashboard that 
can be configured. 

| 6.7.4-3 

Financial reports will have access to all data and fields in the financial, accounts receivable, and billing modules. 

m 

The Financial Reporting and Query Module will have an easy-to-use interface as defined during design review and user 
acceptance testing. The interface will allow end users to create (select a title, add fields, add parameters such as dates), 
save, and "keep private" or "make public" based on security and access. The user interface will have simple look-ups to 
find fields or create parameters. 


Fully Conforming 
NonEonforming 
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H 

The Financial Management application will include a robust reporting tool that generates canned and custom reports. 

The reporting tool will allow the viewing, running, and scheduling of predefined reports, as well as the creation of 
custom reports. 

| 6.7.4-6 

The System will provide audit history and reports to clearly track changes in data. 


The Financial Reporting and Query Module will allow for all reports to be exported to pdf, .csv. Excel, or other defined 
format. 


Financial Reporting and Query Module will allow for configured, ad hoc queries, saved queries and pre built reporting. 


Access to the Financial Reporting and Query Module will be controlled through the same role based security model as 
the financial, accounts receivable and billing modules. 

6.7.4-10 

Reports built by the SI as part of the initial implementation will include at minimum: 

• Trial balance 

• next gen ORCA financial Statements 

• Revenue and expenses by Agency 

• Revenue by product 

• Revenue by sale channel 

• Revenue by Agency 

• Revenue by customer account 

• Accounts receivable aging 

• Customer account invoice 

• Customer account invoices by date 

• Customer account statement 

• Customer account statements by date 

6.7.4-11 

Financial reports will be created and used to make manual entries in the participating Agencies' GLs. The reports will 
provide the accounting details required to make the journal entries in the Agencies' financial management applications. 
No electronic interfaces between the fare collection and the Agencies' existing financial systems will be required. 

Section 6.8 Central Payment Application 

m 

The System will use solution that meets the ISMS security control baseline for all funding sources stored within the 
System. The SI shall make use of a third-party service so that no payment data, encrypted or otherwise, is stored within 
the System. 

6.8-2 

The integration to the payment processor will be built using an API. All devices and systems processing payments will use 
the API to connect to the Sl-provided Central Payment application. 

6.8-3 

All devices and systems accepting payments will support a configurable amount for limits associated with a signature on 
credit card transactions. 

m 

If a payment authorization is not completed within a configurable time period, or is interrupted, the ATP will cancel the 
transaction and notify the customer if possible and/or Agency staff. Any canceled transactions will be recorded. 

6.8-5 

The System will maintain payment records to support the auditing of all payments processed, and to support payment 
dispute and chargeback resolution. 

6.8-6 

The SI shall be responsible for integrating with the bank card processor/processing service for sales through all fare sales 
channels processed by the back office that uses a single merchant account with a transit merchant category code. 


6 . 8 -: 


The customer mobile app and customer website will support refunds. The refund process will be detailed and approved 
during design review. Refunds for bank card purchases will be available for automatic refund without having to re-enter 
the bank card number._ 


Fully Conforming 
NonEonforming 
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6.8-8 

Devices and systems requiring an interface to the payment processor include, but are not limited to: 

• ATP 

• VMs 

• CSTs 

• CRM application (for the call center) 

• Customer website 

• Customer mobile app 

• Validators (for open payments in the future) 

The System will be able to support open payments if accepted in the future. 

6.8-9 

All devices and systems accepting payments will support split payments, with the use of up to three (3) funding sources 
to complete payment for a single sale, including use of multiple credit/debit cards, ACH funding sources, and cash. 

6.8-10 

All devices and systems accepting payments will support configurable minimum and maximum payment amounts. The 
minimum and maximum amounts will be able to be independently set by distribution channel and payment type, 
including by credit/debit card type (e.g.. Visa, MasterCard, American Express, and Discover). 

6.8-11 

During payment processing, the System will be able to identify pre-tax benefit cards issued by the government and pre¬ 
tax benefit providers based on the Issuer Identification Number (IIN). Stored value and products loaded using this fare 
media will be identified as such and segregated within the transit account to support compliance with all applicable IRS 
regulations. 

6.8-12 

The System will accommodate the ability to change bank processors in the event that the Agencies wish to do so. The 
Program needs the SI to be responsible for integration tasks. 

6.8-13 

Bank card processing for the retail network and WSF toll booths will be performed through their separate point of sale 
systems. 

6.8-14 

The Central Payment application will accept credit and debit cards through all channels, including customer service 
offices, VMs, call centers, and customer website. 

6.8-15 

The Central Payment application will accept ACH transfers through the customer website, customer mobile app, and the 
CRM. 

6.8-16 

The System will support full transaction-level reconciliation of all bank card payments processed through the System, 
including those accepted for customer account orders. This reconciliation will be automatic with any exceptions 
reported, the process will be approved during design. 

6.8-17 

The Program needs the SI to provide all labor and materials required for Central Payment application testing, including 
but not limited to all bank cards, and all support services and facilities required to stage, inspect, and test all hardware 
and software being supplied. 

6.8-18 

Chargebacks will be automatically processed so that any remaining value associated with the purchase will be blocked. 

6.8-19 

The Central Payment application will incorporate any services supported by the payment processor for the automated 
update of card data on file. 

Section 6.9 Configuration & Change Management Application 

6.9-1 

The SI will deploy a COTS, preferably SaaS, solution for software configuration management and version control. 

6.9-2 

All workflow functionality and setup within the Configuration & Change Management application will be drag and drop 
to support simple administration and implementation. 

6.9-3 

The Configuration & Change Management application will support the maintenance and consistency and updates within 
each software release. 

6.9-4 

The Configuration & Change Management application will have functionality to track the physical attributes, design, and 
operational information for each environment throughout its life. 


Fully Conforming 
NonEonforming 
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The Configuration & Change Management application will support the planning, designing, development, and release for 
all software development. 


The Configuration & Change Management application will have functionality to allow for collaborative team software 
development._ 


Software updates to back office software, databases, and associated modules will be centrally managed with appropriate 
version control in place. Software releases will only be released by authorized system administrators following Agency 
roval. 


Functionality will allow for issue and resolution tracking. 


Functionality will allow for prioritization of tasks and development 


Each update will have a unique version number and include an activation date and time if applicable. Updates will be 
able to be downloaded and applied at that activation time, or activated immediately after download and verification is 
confirmed. 


The Configuration & Change Management application will have functionality to manage and monitor software 
capabilities, development, testing, environments, and migrations between environments._ 


The Configuration & Change Management application will have workflow functionality to review and approve tasks, 
assign tasks, and monitor workloads._ 


Section 6.10 Tariff Management Application 


SI will design, build, and deploy a Tariff Management application that integrates with all the back office components 
allowing fare product changes and updates to be controlled by the Agencies. 


The fare tables will be easy to view, review, and test when entering during creation of initial tables and any future fare 
updates. This will be addressed during design and testing._ 


The Tariff Management application will allow configuration by Agency, sales channel, location, and individual device. 


The Tariff Management application will integrate with frontend devices including the website and physical equipment 
where applicable. 


The Tariff Management application will have role-based security access to control who can access what based upon role. 


The Tariff Management application will allow a separate workflow process for each Agency and regional fare product so 
that changes can go through a formal review and approval process._ 


The Tariff Management application will allow for design of fare sets. This includes all fare tables, fare rules, and other 
parameters necessary to support the fare structure by Agency by product. Different rules and structures will be available 
by Agency by product. Regional fare products will be configured centrally. 


The Tariff Management application will be able to manage, store, and deploy an active fare set and at least two (2) 
pending fare sets. An active fare set will become effective immediately upon publication. Pending fare sets will be able to 
be activated manually, or automatically based on a future activation date configured. 


The Tariff Management application will have an online manual and training guide. 


The Tariff Management application will allow Agencies to view and compare draft fare sets and changes to active and 
pending fare sets by Agency and regionally, by sales channel, and by fare product. 


The System will have the flexibility to support Agency fare changes without software modifications. All fare changes will 
be through fare table and other configuration changes. 



Comments 


The support for this is generally provided by the Atlassian tools. However, the source code and 
version control for the INIT software in Karlsruhe, is not accessible to customers since this also 
includes version control to other projects. If some of the SW or configuration is developed in such 
way that the agency have access to the source code, this can be held in a Bitbucket (GIT) repository. 




The support for this is generally provided by the Atlassian tools. However, the source code and 
version control for the INIT software in Karlsruhe, is not accessible to customers since this also 
includes version control to other projects. If some of the SW or configuration is developed in such 
way that the agency have access to the source code, this can be held in a Bitbucket (GIT) repository. 
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6.10-12 

The back office will be capable of supporting at least four (4) fare tables (one current, two future, and one past), which 
includes all fare and configuration data required to sell and validate fare products. 

6.10-13 

The Tariff Management application will have the ability to roll back to a previously used fare set. 

6.10-14 

All fare product configurations will be able to be performed by the Agencies, as well as by the SI during implementation 
and throughout the warranty and software maintenance agreement terms. 

6.10-15 

The System will allow fare set changes on a frequent, including daily, basis without regard to additional pending changes. 
For example, an Agency could change fare rules regardless of other Agency changes that are pending. 

Section 7 Fare Media 

Section 7.1 General Capabilities 

7.1-1 

Smart card media will be available for competitive purchase from multiple U.S. sources. The SI shall provide the 
specifications and associated documentation necessary to support the Agencies' future procurement of smart card 
media from third-parties. 

7.1-2 

All fare media will be designed for use in an account-based system, and serve as a credential for accessing closed-loop 
transit accounts maintained within the back office. No data will be written to the media when loading or using fare 
value, with the exception of data required to support risk mitigation techniques. 

7.1-3 

The SI shall provide the initial supply of fare media to support the first year of operation following system launch. 

7.1-4 

The System will support a one-time charge, or "card fee," for issuance of new fare media. This card fee will be able to be 
configured based on fare media type, passenger type, and distribution channel, and may be set to zero for specific fare 
media types, specific passenger types, or sales through specific channels. 

7.1-5 

Agency-specific and regional fare products will be sold for use on next gen ORCA media. 

7.1-6 

Sales channels and fare distribution devices will have the capability of issuing EU fare media. The System will also 
support other media types such as LU fare media should they be needed in the future. 

7.1-7 

The Program needs the SI to design, develop, and provide manufacturing and delivery of all fare media required for 
successful deployment of the new System. The Program needs the SI to deliver all graphics files and related materials 
required for manufacture of the fare media to the Agencies for review and approval no less than 120 calendar days prior 
to the start of fare media production. 

7.1-8 

All supplied fare media will undergo a comprehensive quality assurance process prior to delivery to confirm adherence 
to all required performance standards and certifications. Media that fail to meet these capabilities will be replaced by 
the SI at their own expense. 

Section 7.2 Fare Media Format 

7.2.1-1 

All contactless fare media will comply with the most recent versions of ISO/IEC 14443-1 for physical characteristics and 
ISO/IEC 7810 ID1 for physical dimensions. Thickness and other physical characteristics not defined by these standards will 
be finalized during design reviews. 

7.2.1-2 

EU fare media will be constructed of appropriate durable materials for a minimum useful life of 10 years. The media will 
comply with the most recent versions of ISO/IEC 10373 and ANSI INCITS 322 for durability. Media supplied by the SI that 
fails to meet these capabilities will be replaced by the SI at their own expense. 

7.2.1-3 

The System will support the printing of personalized and customized media using the CST. 

■ 

In the future, the System may accept media issued by third parties, including but not limited to: 

• Reduced fare media (youth, senior, disabled, low income, etc.) 

• Employee IDs 

• College and school IDs 

7.2.1-5 

The fare media will have read/write performance of not less than 200,000 read/write cycles. 

7.2.1-6 

In addition to the contactless interface, EU fare media may be produced with barcodes and/or magnetic stripes to allow 
interaction with third-party systems outside the scope of the new System. If required, the format and data content of 
any barcodes or magnetic stripes will be defined during design review. 
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7.2.1-7 

All fare media will include an etched, unique non-sequential serial number for the purposes of traceability that is 
separate from the credential and smart card Unique Identification Number (UID) and a three-digit security code. 

m 

Fare media will be produced based on branding developed by the Agencies and a card design developed jointly with the 
SI. Fare media will also be produced with one or both sides left blank for custom printing following manufacture. 

7.2.1-9 

All pre-printed graphics will be protected by a clear coat that covers the entire surface of the card. This coating will not 
prevent secondary printing of cards. 

7.2.1-10 

EU fare media will be printed using a four-color process, front and back, and support edge to edge printing. 

n 

The transit payment application will be compatible with all modern MIFARE formats, including but not limited to: 
Ultralight C, MIFARE Plus, DESFire, and SmartMX. The specific platform to be used for the Agency-issued fare media will 
be proposed by the SI and approved during design review. 

7.2.2-2 

The fare media will support account-based closed-loop fare payments in both single- and multi-application smart card 
environments. 

7.2.2-3 

The fare media format will support a minimum of a 7 byte smart card Unique Identification Number (UID). 

7.2.2-4 

In addition to the 14443 contactless interface, EU fare media may be produced with Indala 125KFIz, 26 bit Weigand 
proximity technology to support King County Metro issuing a single card for ORCA use and its access control for 
employees. If required, the format and data content of any additional contactless interface will be defined during design 
review. 

7.2.2-5 

The transit payment application will support the secure storage of a unique credential used to access a transit account 
maintained within the back office. The secure transit account credential will not be the smart card UID or transit account 
number used within the back office, and will not be printed on the media or otherwise accessible using a non-system 
device. 

7.2.2-6 

The transit application will support the encoding of additional data at the time of manufacture and use to support risk 
mitigation techniques. 

7.2.2-7 

The Sl-developed transit payment applications and formats will be fully owned by or licensed to the Agencies, including 
the right to distribute specifications to third-parties for media production and to support multi-application smart card 
implementations without further approval, license, or payment. 


The Program needs the SI to publish bit-level specifications for all transit payment applications across all supported fare 


media within the System, including information on all security protocols necessary to access and encoded data on the 
media. The software specifications will be subject to Agency review and approval during design review. 







































